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Preface 


The  goal  of  this  work  was  to  establish  a  vahd,  independent  Air  Force  site  for  accuracy 
testing  of  the  Magnetospheric  Specification  Model  (MSMT).  This  report  is  limited  in  scope  to 
a  discussion  of  the  construction  and  authentication  of  the  testing  platform  at  the  Air  Force 
Institute  of  Technology,  along  with  presentation  of  an  initial,  limited  accuracy  study. 

It  is  my  experience  that  the  details  and  difficulties  associated  with  MSM  research  are 
overwhelming  to  the  beginner.  This  paper  is  intended  to  document  in  one  place  some  of  the 
foundational  information  necessary  to  begin  MSM  research.  It  is  wntten  from  the 
perspective  of  a  complete  novice,  someone  who  began  knowing  nothing  at  all  about  the 
subject.  It  is  written  is  a  style,  and  includes  details,  that  will  hopefully  make  it  possible  for 
another  novice  to  attain  a  working  knowledge  of  the  model  in  short  order.  Those  who  already 
understand  MSM  may  find  it  simplistic.  They,  however,  will  be  able  to  determine  whether  all 
the  requisite  issues  have  been  documented,  and  are  cheerfiilly  invited  to  supply  constructive 
criticism. 

The  bulk  of  my  four  months  of  research  time  was  invested  in  contacting  scientists  with 
MSM  expertise,  gathering  and  documenting  information,  installing  and  testing  software,  and 
acquiring  and  vahdating  databases.  In  short,  I  had  to  establish  a  credible  testing  platform  for 
the  model  at  AFIT.  The  bulk  of  model  validation  remains  to  be  done.  I  feel  very  strongly  that 
the  potential  exists  for  another  AFIT  student  to  significantly  extend  the  analysis  of  MSM 
beyond  the  acciuracy  study  presented  in  Chapter  5. 

I  would  like  to  thank  my  advisor  Dr.  David  Weeks  for  his  unfailing  optimism  and  zeal 
for  learning  which  he  displayed  during  the  course  of  my  thesis  work.  Special  thanks  also  go 

iii 


to  Dr.  Robert  Hilmer,  Dr.  Bonnie  Hausman,  and  Capt.  Tom  Smith  for  prolonged  patience  and 
expert  assistance  in  answering  hundreds  of  questions.  The  members  of  my  committee.  Dr. 
William  Bailey  and  Capt.  DerriU  Goldizen  provided  needed  corrections,  guidance  and 
encouragement,  for  which  I  am  grateful.  The  AFTT  Physics  Department  generously  allowed 
for  TDY  travel  to  Falcon  AFB  and  Phillips  Geophysics  Laboratory,  as  well  as  to  an  Air  Force 
Space  Model  Review  Meeting.  Without  that  support  this  research  effort  would  not  have  be 
possible.  The  many  scientists  and  officers  whom  I  met  at  these  places  all  added  to  my 

understanding  of  the  complex  task  of  mastering  MSM. 

At  the  outset  of  this  effort,  my  conaputer  knowledge  was  infamously  poor.  Through 
the  assistance  of  persevering  Mends  such  as  Charfie  Brennan,  Roy  Calfas,  Matt  Smitham  and 
Karyl  Davis,  I  was  able  to  come  up  to  speed  quickly.  I  owe  them  many  thanks. 

Capt.  Cliff  Dungey  devised  the  original  idea  of  MSM  research  at  AFTT.  For  that,  and 
the  many  other  things  he  has  done  to  support  the  AFIT  Space  Physics  program,  a  big  thanks. 

Many  people  in  the  Dayton  community  have  been  warm  hosts,  especially  the  members 
of  Behevers  Assembly.  Eric  and  Naomi  Hemp  are  one  of  a  kind  Mends.  Thank  you. 

My  wife  Linda  deserves  the  warmest  and  most  sincere  thanks  of  all.  She  managed  to 
support  me  in  gmeling  times  during  our  1 8  month  stay  at  AHT,  while  loving  and  caring  for 
our  six  children,  one  on  whom  was  bom  during  my  thesis  quarter.  Each  of  our  children  have 
been  mighty  good  troopers  during  the  whole  ordeal  too.  I  love  them  aU  dearly. 

Finally,  I  give  thanks  to  Almighty  God  for  His  sustaining  grace,  in  every  circumstance. 


Clark  M.  Groves 
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Abstract 


The  Magneto  spheric  Specification  Model  (MSM)  is  a  computer  simulation  which 
specifies  energetic  charged  particle  fluxes  in  the  earth's  magnetosphere.  Developed  by  Rice 
University  for  the  United  States  Air  Force,  it  is  a  first  of  its  kind  model.  Earth's 
magnetosphere  is  of  enormous  size  and  complexity,  and  is  the  hostile  operational  arena  for  a 
wide  variety  of  critical  mihtary  hardware.  SateUites  are  especially  subject  to  environmental 
damage  by  peaks  in  energetic  charged  particle  flux  induced  by  solar  wind  dynamics.  MSM 
receives  ground  based  magnetometer  data,  solar  wind  data,  and  direct  and  modified  in  situ 
data  as  inputs.  It  then  simulates  the  magnetohydrodynamics  of  particles  and  fields  and 
computes  the  flux  of  particles  between  2  and  1 0  Earth  radii  in  the  energy  range  1  to  1 00 
keV.  Conqjarison  of  model  flux  output  with  in  situ  particle  flux  measurements  yields  an  error 
estimate  of  the  model's  simulation.  Selective  variation  of  input  data  quantifies  model 
sensitivity  to  data  availability.  A  study  of  model  error  as  a  fimction  of  time  reveals  a  diurnal 
error  peak,  indicating  a  model  weakness  in  a  particular  magnetic  local  time  zone. 
Differentiation  of  error  as  a  function  of  magnetometer  indices  reveals  model  accuracy 
sensitivity  with  respect  to  geomagnetic  activity. 
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TESTING  AND  VALIDATION  OF  THE 
MAGNETOSPHERIC  SPECIFICATION  MODEL 

1.  INTRODUCTION 

The  Magnetospheric  Specification  Model  (MSM)  is  a  con^uter  simulation  which 
specifies  energetic  charged  particle  fluxes  in  the  earth's  magnetosphere.  It  was  the  first 
operational  computer  simulation  of  the  space  environment  in  history.  MSM  was  developed  in 
response  to  a  vital  and  growing  military  mission  need  and  represents  the  genesis  of  a 
revolution  in  spacecraft  mission  support. 

1.1  Air  Force  Mission  Need 

Over  the  past  30  years,  many  crucial  military  systems  have  been  developed  which 
operate  in  the  near-earth  space  realm.  This  charged  particle  environment  impacts  the  lifetime 
and  reliability  of  satellites  through  radiation  effects  and  spacecraft  charging.  Many  instrument 
anomalies  occur,  and  spacecraft  operators  and  systems  engineers  must  be  able  to  rapidly 
isolate  causes  and  implement  corrective  actions.  In  addition,  military  satellites  may  someday 
be  targets  during  wartime,  even  though  forbidden  by  international  treaty.  A  warfighting 
commander  must  be  able  to  rule  in  or  rule  out,  with  a  high  degree  of  confidence,  any  possible 
adversarial  strikes  against  our  assets.  Delineating  satellite  damage  due  to  enemy 
countermeasures  from  environmentally  induced  damage  is  imperative.  However,  these  actions 
are  possible  only  if  there  exists  a  means  to  specify  the  satellite  operation  environment. 

During  the  rapid  development  era  of  space  operations,  there  has  been  an  absence  of 
analysis  capability  for  the  space  environment.  There  are  very  few  platforms  devoted  to 
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providing  measurements  of  Earth's  space  plasma  environs,  especially  relative  to  the  size  of  the 
system.  The  cost  of  significantly  increasing  this  number  is  prohibitive.  The  only  reahstic 
option  for  specifying  and  eventually  forecasting  space  conditions  is  via  computer  modelling. 
The  need  for  an  operational  suite  of  space  models  as  a  force  enhancer  is  immediate. 

1.2  Solar-Terrestrial  Environment 

A  basic  understanding  of  the  solar-terrestrial  environment  is  necessary  on  the  part  of 
the  reader.  Its  detailed  description  is  outside  the  scope  of  this  document.  An  overview^  of  the 
subject,  limited  to  a  phenomenological  discussion  of  aspects  relevant  to  understanding 
charged  particle  flux  patterns  in  the  magnetosphere,  is  provided  in  the  Appendix. 

1.3  Space  Model  Development  History 

Air  Force  space  model  research  is  in  its  infancy.  The  Magneto  spheric  Specification 
Model  (MSM),  the  focus  of  this  study,  became  operational  in  July  1995  as  the  first 
operational  computer  simulation  of  the  space  environment  in  history.  A  brief  overview  of  its 
programmatic  development  is  instructive  as  a  background  to  the  current  research  effort. 

US  Space  Command  was  created  in  1985.  The  need  for  models  to  specify  the  space 
environment  quickly  came  to  the  fore.  In  response.  Air  Weather  Service  (AWS)  in  1986 
initiated  a  research  and  development  project  known  as  the  Space  Environmental  Technology 
Transition  (SETT)  program  under  the  tutelage  of  Col.  Thomas  Tascione.  This  is  an 
incremental  plan  to  develop  seven  independently  operating  "building  block'  models  of  the 
space  environment  from  the  sun  to  the  earth.  A  second  plan  exists,  the  Integrated  Space 
Environmental  Model  (ISEM),  to  develop  an  executive  system  which  fully  couples  all  the 
models  and  integrates  them  with  the  50th  Weather  Squadron's  (50WS  -  formerly  Air  Force 
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Space  Forecast  Center)  real-time  space  and  geophysical  database  at  Falcon  AFB,  CO.  SOWS 
will  be  the  end-user  of  the  models  in  service  to  Space  Command  operations. 

SETT  program  management  at  AWS  falls  under  the  office  of  Directorate  of 
Technology,  Plans  and  Programs,  HQ  AWS/XOX.  From  the  outset,  responsibility  fell  to 
Phillips  Laboratory  Geophysics  Directorate,  Hanscom  AFB  (PL/GP),  for  basic  research  and 
development  of  the  SETT  suite.  Oversight  of  the  MSM  at  PL  feU  under  Dr.  Mike 
Heinemann  (PL/GPSG).  In  1986,  PL  contracted  Rice  University  to  design  the  model  in 
accordance  with  Air  Force  Needs  Statement  0586.  Dr  John  W.  Freeman,  et.  al.,  of  the 
Department  of  Space  Physics  and  Astronomy  undertook  the  obligation.  The  code  was 
subsequently  delivered  by  Rice,  and  MSM  became  operational  at  SOWS  in  July  1995,  after 
user  interface  software  development  by  Hughes  STX  Corporation,  Colorado  Springs,  under 
the  direction  of  Dr.  Verne  Patterson. 

The  Rice  developers  conducted  some  testing  of  the  model  as  an  integral  part  of  R&D. 
SOWS  desired  independent  testing.  From  1992-1994,  the  United  States  Air  Force 
Environmental  Technical  Apphcations  Center  (ETAC),  tasked  by  Phillips  Lab,  undertook  a 
limited  sensitivity  test  on  MSM.  Responsibility  fell  to  Capt.  Tom  Smith  of  the  Simulations 
and  Techniques  Branch  (SYT) .  Although  significant  work  was  done,  the  study  was  never 
completed  and  a  fioal  report  was  never  published.  Tasking  for  ETAC  analysis  of  SETT 
models  has  since  been  terminated.  The  progress  made  served  as  the  foundation  for  this 
current  work,  as  discussed  later  in  this  report. 

SOWS  analysts,  under  the  supervision  of  Mr.  Kevin  Scro,  subsequently  attempted  to 
accomplish  limited  studies  of  their  own  on  MSM.  This  proved  to  be  an  untenable  option  due 
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to  the  pressures  of  50WS's  operational  mission  and  manning  cuts  for  technical  officers. 

MSM  development  has  spanned  many  years.  Expertise  and  resources  relating  to  the 
model  exist  in  a  complex  network  of  scientists  and  officers  at  many  locations.  Comprehension 
^nd  compilation  of  this  knowledge  was  a  major  effort  at  the  outset  of  this  project.  It  is  useful 
for  a  follow-on  researcher  to  understand  the  chronology  of  MSM  evolution  and  form 
working  contacts  with  the  sites  and  participants  involved.  AWS/XOX  convenes  a  semi¬ 
annual  Space  Model  Review  Meeting,  to  provide  the  scientists  and  agencies  within  the  Air 
Force  space  modelling  commumty  with  a  forum  for  face  to  face  interaction. 

1.4  Research  Objective  and  Scope 

The  goal  of  this  work  was  to  establish  a  valid,  independent  Air  Force  site  for  accuracy 
testing  of  the  Magnetospheric  Specification  Model.  This  report  is  limited  in  scope  to  a 
discussion  of  the  construction  and  authentication  of  the  testing  platform  at  the  Air  Force 
Institute  of  Technology,  along  with  presentation  of  an  initial,  limited  accuracy  study,  with 
recommendations  for  further  analysis. 

This  work  serves  as  the  basis  for  a  complete  analysis  of  the  MSM.  The  report  is 
intended  to  document  foundational  information  necessary  to  achieve  credible  research.  In 
addition,  it  is  strongly  hoped  that  this  project  inaugurates  the  official  sanction  and  funding  of 
independent  beta  testing  of  other  SETT  models  at  the  Air  Force  Institute  of  Technology. 

1.5  Air  Force  Impact 

One  weak  link  surfaces  in  the  Air  Force  space  model  formation  process.  Currently,  no 
designated  site  exists  for  independent  vahdation  studies.  Creating  a  SETT  model  test  site  is  a 
monumental  task.  In  the  final  analysis,  however,  independent,  operations  oriented  feedback 
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is  essential  to  the  development  of  space  models  which  will  best  accomphsh  the  Air  Force 
mission.  Since  MSM  is  the  most  developmentally  mature  of  the  SETT  suite,  it  was  chosen  as 
the  vehicle  for  establishing  the  pattern  of  AFIT  /  SETT  model  testing. 

The  in-residence  AFIT  graduate  space  physics  program  is  uniquely  positioned  to  join 
the  Air  Force  space  model  development  team  with  exceptional  value  added  capacity.  Officers 
engaging  in  model  related  thesis  work  foster  invaluable  networks  in  the  research  community 
and  gain  detailed  knowledge  of  state-of-the-art  models.  Upon  graduation,  these  officers  go 
to  Space  Command  assignments  to  become  operational  users  of  the  models.  These  dynamics 
promise  to  promote  synergism  and  clarity  between  research  centers  and  operations  centers 
rather  than  the  proverbial  strain.  Moreover,  AFTT  provides  AWS  a  beta  test  site  without  the 
overhead  of  subcontractors.  Faculty/scientists  and  student/researchers  are  already  in  place. 

An  AFIT  /  SETT  beta  test  site  scenario  is  a  tvin-win  paradigm  for  every  Air  Force 
member  on  the  team.  AWS  gains  independent  validation  of  their  models  at  minimal  cost;  Air 
Force  Space  Command  gains  improved,  tested  models  while  simultaneously  having  its  future 
officers  trained  as  experts  in  new  operations  tools;  research  labs  gain  a  unique  and  lasting  link 
to  operations  feedback;  AFIT  expands  its  singular  role  of  mission  relevant  research  and 
training;  AFIT  officers  maximize  their  mission  tailored  graduate  education. 

1.6  Scientific  Overview  of  MSM  (1) 

MSM  simulates  Earth's  magnetosphere  and  provides  a  basis  for  determining  energetic 
particle  fluxes  at  arbitrary  positions  and  times.  This  simulation  includes  a  representation  of 
the  electric  anrl  magnetic  fields,  as  well  as  the  analysis  of  particle  fluxes  in  the  magnetic  equal- 
trial  plane  from  2  to  10  Earth  radii  (Re)  for  particle  energy  ranges  between  1  and  100  keV. 
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Particles  are  moved  according  to  bounce-averaged  equations  of  adiabatic  drift  in  the 
electric  field.  They  can  be  mapped  along  equipotential  magnetic  field  lines  on  or  off  of  a 
coordinate  grid  in  the  magnetospheric  equatorial  plane.  The  electric  field  is  determined  by 
merging  a  convective  model  for  the  inner  magnetosphere  with  a  parameterized  model  of  the 
ionospheric  electrostatic  potential  distribution.  The  magnetic  field  representation  used  is  a 
parameterized  current-driven  model  that  determines  the  magnetic  field  from  the  superposition 
of  the  earth's  magnetic  dipole  moment  and  the  magnetic  fields  caused  by  the  major  current 
sources:  Chapman-Ferraro  current,  equatorial  ring  current,  and  the  cross-tail  current  sheet. 

MSM  is  designed  to  exploit  all  available  environmental  data  resources  at  SOWS,  where 
it  operates.  It  accesses  seven  environmental  input  parameters:  Kp  index,  Dst  index,  low 
latitude  midni^t  boundary  of  the  auroral  zone,  polar  cap  potential  drop,  polar  cap  potential 
pattern,  solar  wind  velocity,  and  solar  wind  density. 

MSM  outputs  magnetospheric  electron  and  ion  differential  fluxes  as  fimctions  of 
energy  and  position.  In  addition,  the  model  provides  precipitating  electron  fluxes  in  the 
auroral  zone,  as  well  as  the  ionospheric  electrostatic  potential. 

1.7  Sequence  of  Presentation 

Chapter  2  will  present  a  review  of  a  previous  MSM  validation  study,  followed  by  an 
overview  of  the  general  research  approach  adopted  for  this  project.  Chapter  3  wiU  present 
concepts  for  understanding  MSM  code,  related  data  and  corollary  software.  Chapter  4  will 
discuss  the  issues  which  surfaced  in  constructing  a  valid  research  platform  for  the  model. 
Chapter  5  highlights  accuracy  studies  accomplished.  Conclusions  and  recommendations  for 
further  study  complete  the  report. 
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2.  PAST  AND  PRF.SRNT  VAI.TDATION  EFFORTS 


2.1  Overview  of  Previous  Validation  Effort 

The  draft  document  Validation  of  the  MSM.  and  some  undocumented  work  done 
subsequently  (acquired  by  personal  communication),  represent  the  uncompleted  ETAC  study 
(2).  Those  analyses  have  been  presented  orally  at  Space  Model  Review  Meetings. 

The  preface  of  the  ETAC  draft  identifies  the  tasking  of  the  project  as  received  from 
Phillips  Laboratory:  1)  establish  the  operating  reliability  of  the  MSM,  2)  determine  the 
model's  accuracy,  and  3)  investigate  the  usefulness  of  the  MSM  as  a  satellite  anomaly  analysis 
tool  for  use  at  SOWS  (2:iv).  ETAC's  draft  report  includes  a  chapter  on  each  of  these  topics. 

Private  communication  with  the  author  indicates  that  tasking  one  was  completed  (3). 
Personal  experience  in  the  AFTT  study  also  bears  this  out.  ETAC  used  MSM  version  3.0  and 
reported  numerous  run  time  problems.  The  present  project  used  MSM  version  5.0  and 
experienced  none  of  the  reliability  problems  related  to  version  3.0.  ETAC's  feedback  to 
model  developers  led  to  the  addition  of  useful  error  traps  and  improved  operating  reliability  in 
subsequent  MSM  versions.  This  highlights  the  value  of  independent  feedback.  Operating 
reliability  has  improved  to  the  degree  that  the  AFIT  research  effort  did  not  uncover  any 
additional  items  in  this  area. 

ETAC's  efforts  on  tasking  two  were  extensive  in  scope.  However,  difficulties  were 
encountered  in  ETAC's  initial  execution  of  their  accuracy  studies.  The  accuracy  results  in  the 
draft  were  questionable  due  to  an  inadvertent  mishandling  of  input  data.  In  addition, 
subsequent  to  ETAC's  research,  certain  software  routines  used  to  produce  input  files  from 
satellite  data  had  undergone  revision,  requiring  use  of  updated  files  in  future  studies. 
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These  facts  motivated  AFTT  researchers  to  choose  accuracy  testing  as  a  primary,  initial 
focus  in  the  study  of  MSM.  In  order  to  shorten  the  learning  curve  for  AFIT’  research,  ETAC 
graciously  provided  the  components  of  their  testing  platform  as  a  starting  framework  for  this 
study.  This  included  the  input  data  files,  MSM  source  code,  in  situ  comparison  data  files,  and 
post-processing  analysis  software  they  used.  (Chapter  3  of  this  report  defines  these  items.) 

The  chapter  in  ETACs  draft;  report  on  the  usefulness  of  MSM  as  a  satellite  anomaly 
analysis  tool  indicates  that  they  made  some  progress  on  tasking  three.  This  is  a  critical  area 
for  further  research.  However,  it  was  not  possible  to  extend  the  initial  research  efforts  at 

AFIT  to  include  this  tasking. 

2.2  Assumptions  About  Previous  Validation  Effort 

Since  the  current  study  was  to  be  an  independent  AFTT  accuracy  analysis,  nothing  was 
taken  for  granted  regarding  the  items  received  from  ETAC.  Instead,  a  series  of  reviews  was 
tmdertaken  to  establish  the  vahdity  of  each  component  of  the  testing  platform.  Data  files  were 
updated,  corrected,  or  replaced  as  necessary.  Original  sources  were  reacquired  whenever 
possible.  Post-processing  software  was  also  scrutinized.  Programs  were  corrected  as 
necessary,  or  in  some  cases,  original  software  was  written  to  accomplish  a  needed  task.  AH  of 
these  issues  are  discussed  in  detail  in  Chapter  4. 

2.3  Current  Research  Approach 

The  goal  of  this  research  effort  was  to  establish  an  independent,  up-to-date  testing 
platform  for  MSM,  unambiguously  documenting  the  process  undertaken,  and  ultimately 
performing  credible  accuracy  studies  on  the  model.  This  complex  task  had  to  be  broken  down 
into  three  manageable  partitions  as  a  general  research  approach:  1)  conceptually  understand 
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MSM  code,  along  with  supporting  data  and  software,  2)  identify  and  solve  issues,  problem 
areas  and  pitfalls  related  to  establishing  a  vahd  testing  platform,  and  3)  adopt  and  execute  an 
accuracy  testing  strategy.  Each  of  the  next  three  chapters  reports,  in  order,  on  how  the  triad 
of  steps  in  the  research  approach  was  carried  out.  Before  proceeding  to  cover  those  topics. 
Table  1  on  page  10  is  provided  to  prime  the  reader's  understanding  of  the  research  approach. 
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TABLE  1 

QUESTIONS  AND  ISSUES  UNDERLYING  THE  RESEARCH  APPROACH 


QUESTIONS  onMSM 

ISSUES 

How  is  MSM  organized? 

-  Understanding  a  large,  complex  code. 

What  are  model  inputs? 

-  Where  did  input  data  come  from?  Are  these  reliable  sources? 

-  Is  this  raw  environmental  data?  If  not,  what  modifying 
algorithms  were  employed  to  create  the  input  files? 

-  Did  the  algorithms  employed  to  make  changes  imdergo 
revision,  creating  the  need  for  updated  input  files? 

-  Is  data  properly  formatted?  Proper  units?  Data  gaps  a  factor? 

How  does  one  get  the 
model  to  successfully 
execute? 

-  Does  one  have  to  modify  the  code  to  get  it  to  execute? 

-  Is  the  version  of  MSM  code  used  a  factor? 

-  Are  there  any  Fortran  compiler  or  debugging  issues? 

-  Are  there  data  storage,  operability  or  automation  issues? 

-  How  about  a  run-time  comparison  of  computer  platforms? 

What  are  model  outputs? 

-  What  are  the  format  and  units  of  the  output  files? 

-  Which  ones  are  needed  for  accuracy  studies? 

-  Is  any  post-processing  software  needed?  What  kind? 

TEST  STRATEGY 

ISSUES 

What  comparison  data 
set  is  used  to  test  the 
model’s  accuracy? 

-  Where  did  comparison  data  come  from?  Reliable  sources? 

-  Is  this  raw  environmental  data?  If  not,  what  modifying 
algorithms  were  employed  to  create  the  comparison  files? 

-  Were  the  techniques  employed  correctly? 

-  Is  data  properly  formatted?  Proper  units?  Data  gaps  a  factor? 

-  Are  issues  related  to  the  sensors  gathering  the  data  a  factor? 

What  comparison 
methods  are  relevant? 

-  Which  comparisons  yield  statistically  relevant  errors? 

-  Which  comparisons  reveal  operationally  significant  insights? 

What  software  tools  are 
needed  to  carry  out  the 
strategy? 

-  How  do  MSM  output  and  comparison  data  get  into 
equivalent  units  and  format,  and  become  equivalently 
interpolated  in  space  and  time? 

-  Is  the  documentation  related  to  the  software  complete  and 
accurate? 
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3.  TTNDFRSTANDING  MSM(4) 


3.1  Background 

The  Rice  developers  produced  the  MSM  Scientific  Description  &  Software 
Documentation  manual  as  the  exhaustive,  general  description  of  the  model  (4:2-2).  The  next 
two  chapters  of  this  report  draw  heavily  from  that  document.  However,  an  attempt  has  been 
made  to  condense  and  synthesize  the  material  found  there,  based  on  lessons  learned  in  this 
study.  Some  undocumented  material  obtained  directly  from  experienced  MSM  scientists  has 
been  added.  The  result  is  intended  to  be  a  concise  guide  for  a  new  MSM  researcher  on  the 
specific  issue  of  understanding  how  to  work  with  MSM  in  the  research  setting. 

The  goal  of  this  chapter  is  to  present  an  overview  of  the  primary  conqjonents  of  the 
MSM  testing  platform.  The  focus  is  on  fimctional  and  conceptual  insights.  The  following 
topics  will  be  covered:  1)  understanding  input  data,  2)  xmderstanding  MSM  code, 

3)  understanding  output  data,  4)  understanding  satellite  comparison  data,  5)  understanding 
post-processing  analysis  software,  and  6)  understanding  miscellaneous  utility  software. 

For  clarity,  it  is  important  to  state  three  things  at  the  outset  of  this  chapter.  First,  each 
of  the  six  areas  mentioned  above  is  highly  interconnected  with  the  other  areas.  This  means, 
for  example,  that  in  order  to  understand  input  data,  you  must  first  know  something  about 
MSM  code.  But  in  order  to  understand  the  code  you  need  to  know  certain  things  about  the 
input.  The  result  is  that  ideas  or  terms  introduced  in  one  section  may  not  be  fully  defined  until 
a  later  section,  where  their  description  more  naturally  fits  into  the  flow  of  the  document. 

Second,  it  is  important  to  repeat  that  this  chapter  focuses  primarily  on  a  conceptual 
understanding  of  the  components  of  the  testing  platform.  Some  techmcal  questions  raised  in 
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the  reader's  mind  by  this  chapter  will  be  not  be  answered  until  the  following  chapter.  Chapter 
4  covers  the  same  topics  as  Chapter  3,  but  with  the  emphasis  on  techmcal  matters. 

The  third  issue  is  a  consequence  of  the  first  two,  and  relates  to  the  use  of  tables  to 
present  what  is  essentially  narrative  material.  The  information  needed  to  understand  MSM  is 
lengthy,  interconnected,  and  technically  detailed.  A  table  format  with  bullet  statements  allows 
an  MSM  novice  to  quickly  cross  reference  information,  and  review  material  at  a  glance. 
Therefore,  it  was  often  selected  as  the  format  of  choice  for  material  in  Chapters  3  and  4. 

3.2  Understanding  Input 

A  natural  starting  point  for  understanding  MSM  is  to  look  at  model  input. 

Functionally,  three  categories  of  input  data  exist;  1)  operator  specified  input,  2)  environ¬ 
mental  input,  and  3)  static  input.  The  functional  distinction  between  the  categories  has  to  do 
with  who  or  what  determines  the  contents  of  the  files  in  each  group.  For  category  1 ,  the  user 
determines  the  content.  For  category  2,  the  environment  dictates  the  content.  For  category  3, 
the  model  itself  provides  the  file  contents.  Specifics  on  each  of  the  three  input  types  follows. 
3.2.1  Operator  Specified  Input  Category 

Table  2  provides  an  overall  description  of  the  operator  specified  category  of  inputs. 
Table  3  follows  with  detailed  information  on  the  individual  files  within  the  category. 

TABLE  2 

OVERALL  DESCRIPTION  OF  OPERATOR  SPECIFIED  INPUT  CATEGORY 

File  names:  msmin,  enchan _ 

-  these  files  must  be  created  by  the  user,  and  are  the  main  operator  interface  to  the  model 

-  these  files  dictate  to  the  model  certain  bookkeeping  and  controlling  information _ 
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TABLES 

DETAILS  ON  OPERATOR  SPECIFIED  INPUT  FILES 


msmin  file 

-  dictates  to  the  model  the  time  window  of  interest  for  model  simulation 

-  tells  the  model  whether  the  run  is  an  initial  start  (cold  start) ,  or  a 
continuation  run  (hot  restart) 

-  provides  input  vehicle  for  identification  headers  and  file  prefix 
designations  for  each  run  -  helps  keep  multiple  runs  organized 

-  provides  the  daily  sun  spot  number 

-  allows  user  to  toggle  on/off  screen  printout  of  results 

-  provides  a  correction  factor  to  the  pep  input  file 

-  allows  user  to  toggle  on/off  between  Kp  only  environmental  data  mode, 
and  full  use  of  all  available  environmental  data  mode 

enchan  file 

-  dictates  to  the  model  the  type  of  charged  particle  sunulation  desired,  as 
well  as  the  energv  channels  of  interest  for  each  particle  type 

3.2.2  Environmental  Input  Category 

Tlie  environmental  category  of  input  data  includes  eight  files.  Table  4  names  the  files 
and  gives  an  overall  description  of  the  input  category,  using  bullet  statements  which  apply  to 
all  files.  Tables  5  and  6  then  give  specific  details  of  each  of  the  individual  files. 


TABLE  4 

OVERALL  DESCRIPTION  OF  ENVIRONMENTAL  INPUT  CATEGORY 


File  names:  fkp ,  dst ,  eqedge ,  pep ,  xipatt ,  swden ,  swvel ,  sumkp _ _ 

-  the  contents  of  these  files  must  be  acquired  by  the  user  fi-om  various  national  data  archival 
sources  or  scientific  centers  (named  in  Table  6) 

-  the  data  must  be  properly  formatted  by  the  user  and  placed  into  files  for  use  by  MSM 

-  the  files  contain  the  environmental  input  data  needed  by  the  model  as  parameters  for  the 

simulation  of  the  magnetosphere  ^  ^  j  i 

-  the  data  in  each  file  must  span  the  entire  time  window  of  interest  for  the  model  run 

-  gaps  in  the  data  stream  are  allowed,  intermittent  or  extended,  except  for  the  fkp  file 

-  in  the  Rice  manual  these  are  called  "event  specific"  inputs  (4:2-4),  i.e.  they  often  are  data 
records  related  to  specific  environmental  events,  such  as  geomagnetic  storms 

-  at  SOWS,  MSM  will  access  their  Environmental  Data  Base,  real  time,  for  these  parameters 
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TABLES 

DETAILS  ON  ENVIRONMENTAL  INPUT  FILES 


FILE 

NAME 

INPUT 

PARAMETER 

DESCRIPTION  OF 
PARAMETER 

UNITS 

TIME 

TAG 

SENSOR 

fkp 

Kp 

-  average  global  magnetic 
activity  index  (Gottingen) 

none 

every  3 
hours 

magneto¬ 

meters 

dst 

Dst 

-  Disturbance  Storm  Time 
Index,  or  equatorial  ring 
current  activity  index 

nano¬ 

tesla 

every  1 
hour 

magneto¬ 

meters 

eqedge 

Equatorward 
Auroral  Edge 

-  low  latitude  midnight 
boimdary  of  the  aurora 

degrees 

latitude 

~  every 

1  hour 

DMSP* 

SSJ/4 

pep 

Polar  Cap 
Potential 

-  electric  field  potential 
drop  across  the  polar  cap 

kvolts 

~  every 

1  hour 

DMSP* 

SSIES 

xipatt 

Cross  Polar  Cap 
Potential  Pattern 

-  Heppner-Maynard 

Model  polar  cap  pattern 
(4:2-18) 

none 

~  every 

1  hour 

DMSP* 

SSIES 

swden 

Solar  Wind 
Density 

-  solar  wind  density 

protons 

/cm' 

hourly 

average 

IMP-8  * 

swvel 

Solar  Wind 
Velocity 

-  solar  wind  velocity 

km 
/  sec 

hourly 

average 

IMP-8  * 

sumkp 

SumofKp's 

-  sum  all  the  Kp  values  for 
a  day;  list  10  day’s  worth 

none 

every  1 
day 

derived 
firom  Kp 

*  DMSP  and  IMP-8  are  names  of  satellites.  SSJ/4  and  SSIES  are  sensors  onboard  DMSP. 
No  details  on  these  items  are  included  in  this  report.  Further  information  is  available  in  the 
MSM  Scientific  Description  &  Sofhvare  Documentation  manual  (4:2-4)  as  well  as  in  the 
ETAC  draft  document  (2:3)  and  a  paper  by  Heelis  and  Hairston  (10). 


3.2.2.1  Environmental  Input  Time  Tagging 

All  data  points  in  the  environmental  input  files  are  marked  by  their  time  of  occurrence 
(they  are  said  to  be  'time  tagged').  Time  tagging  in  each  file  is  independent  firom  that  in  other 
files.  The  model  also  keeps  track  of  its  time  independently  of  any  of  these  time  tags.  It  begins 
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TABLE  6 

FURTHER  DETAILS  ON  ENVIRONMENTAL  INPUT  FILES 


FILE 

NAME 

INPUT 

PARAMETER 

USED  IN  THE  MODEL 

FOR  THE  PURPOSE  OF: 

ORIGINAL 
SOURCE  FOR 
DATA  IN  FILE 

fkp 

Kp 

-  establishing  initial  and  ongoing 
boundary  conditions  for  the  particle 
distribution  functions 

-  generating  proxies  for  missing  data 
in  other  files  using  front-end  models 

-  generating  replacement  flux  values 
using  default  model  (optional) 

-National 

Geophysical  Data 
Center  (NGDC) 
via  WWW* 

dst 

Dst 

-  determining  ring  current  strength  in 
the  magnetic  field  model 

-NGDC  via  WWW 

eqedge 

Equatorward 
Auroral  Edge 

-  determining  auroral  zone 
boundary  in  the  electric  field  model 

-  constraining  the  magnetic  field 
mapping 

-  Philhps  Lab  (PL) 

pep 

Polar  Cap 
Potential 

-  input  to  electric  field  model 

-  University  of  Texas 
at  Dallas  (10) 

xipatt 

Cross  Polar  Cap 
Potential  Pattern 

-  input  to  electric  field  model 

-  University  of  Texas 
at  Dallas  (10) 

swden 

Solar  Wind 
Density 

-  determining  standoff  distance  in  the 
magnetic  field  model 

-  National  Space 
Science  Data  Center 
(NSSDC)  via  WWW 

swvel 

Solar  Wind 
Velocity 

-  determining  standoff  distance  in  the 
magnetic  field  model 

-  NSSDC  via  WWW 

sumkp 

Sum  of  Kp's 

-  determining  high  energy  fluxes 

-  derived  from  Kp 

*  WWW  stand  for  World  Wide  Web. 


its  simulation  at  the  time  tag  declared  by  the  user  in  the  msmin  file  to  be  the  model  'start  time', 
then  moves  forward  in  1 5  minute  intervals.  Environmental  input  data  are  required  at  each 
model  time  step.  However,  input  file  time  tags  are  generally  not  simultaneous  with  the  model 
time  steps.  Therefore,  subroutine  pargen  within  the  MSM  code  performs  a  linear 
interpolation  between  nearest  neighbor  data  points  in  the  input  files,  and  those  are  the  actual 
values  used  by  MSM  at  each  simulation  time  step. 

3. 2.2.2  Environmental  Input  Operating  Modes 

Before  proceeding  to  section  3.2.3  and  the  static  category  of  input  files,  it  is  niq)ortant 
to  cover  a  confusing  issue  regarding  the  model's  use  of  the  environmental  input  files.  It  would 
be  advantageous  to  the  reader  at  this  juncture  to  refer  to  Table  15  in  Chapter  4.  That  table 
and  the  narrative  which  follows  it,  include  a  description  of  line  9  of  input  file  msmin,  which  is 
pertinent  to  this  discussion. 

Table  15  reveals  that  MSM  is  capable  of  operating  in  three  input  modes.  Logically,  it 
makes  sense  that  the  optimal  mode  is  that  one  which  provides  the  model  -with  all  available 
environmental  data  parameters.  However,  MSM  is  capable  of  executing  with  data  gaps  in 
individual  files,  or  with  one  or  more  entire  files  missing,  to  the  point  of  using  IQp  as  the  single, 
default  input.  There  are  significant  differences  in  the  way  in  which  the  model  functions 
internally  in  the  three  input  modes.  The  next  three  sections  attempt  to  make  sense  of  this 
issue.  The  reader  should  pay  particular  attention  to  what  the  Kp  parameter  is  used  for  in  the 

model  in  each  case. 

3.2.2.2.1  Full  Data  Mode 

If  the  user  directs  MSM  to  access  all  mputs,  the  model  employs  a  subroutine  called 
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indata  to  read  all  Kp  values  into  memory  arrays,  along  with  every  other  available 
environmental  inputs.  In  the  perfect  scenario,  all  environmental  input  files  would  be  available 
to  the  model,  with  no  data  gaps  in  any  of  the  files.  In  this  case,  MSM  would  use  Kp  inputs  for 
only  two  purposes.  First,  it  would  initialize  the  particle  distribution  conditions  across  the 
model  grid  using  an  empirically  based  Kp  algorithm.  Then,  as  the  MSM  run  progressed,  the 
model  would  use  this  algorithm  to  establish  flux  conditions  at  the  model  boundary  at  each  new 
time  step.  Only  non-Kp  data  would  be  used  as  input  parameters  for  the  electric  and  magnetic 
field  models,  so  that  the  plasma  distribution  algorithms  could  continuously  update  the  time 
dependent  particle  flux  values  across  the  model  grid. 

The  perfect  scenario  is  usually  modified  to  some  degree.  It  might  happen  that  all  input 
files  are  present,  but  some  of  them  have  data  gaps.  It  might  also  happen  that  one  or  more  files 
are  completely  missing  (other  than  fkp\  with  those  remaining  containing  some  data  gaps. 
Whatever  the  case,  as  long  as  the  user  has  directed  MSM  to  access  all  inputs,  everything 
available  will  be  used  by  the  model  as  described  in  the  previous  paragraph.  The  model  handles 

the  data  gaps  as  described  in  the  next  paragraph. 

In  full  data  mode,  input  data  files  are  tested  for  gaps  in  the  data  stream  by  a  subroutine 
called  pargen.  If  data  are  missing  firom  a  given  parameter,  the  model  responds  in  one  of  two 
ways.  If  the  time  gap  is  small,  values  are  assigned  by  simply  extending  the  linear  interpolation 
between  neighboring  values  in  the  data  file.  However,  if  values  are  missing  for  a  time  gap  in 
excess  of  a  set  length,  the  model  employs  empirical  'fi:ont-end  models'  based  on  Kp  alone  to 
generate  proxies  for  that  parameter  during  those  time  steps.  These  values  are  fed  to  the 
electric  and  magnetic  field  models  to  continue  the  determination  of  time  dependent  particle 
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flux  distributions.  Everything  else  in  the  model  run  functions  as  before. 

32.1.1.1  TCp  Only  Mode  Using  Front-End  Models 

The  most  extreme  modification  of  the  perfect  scenario  above  would  be  to  remove  all 
input  files  from  the  run  directory  except  fkp,  and  yet  direct  the  model  to  access  all  input  data. 
In  this  case,  the  complete  lack  of  data  would  simply  be  treated  as  multiple  extended  data  gaps, 
and  the  front-end  models  would  compute  empirical  proxies  for  all  the  missing  data  as 
described  above.  The  electric  and  magnetic  field  routines  and  particle  distribution  algorithms 
would  operate  exactly  as  before.  The  only  difference  would  be  that  they  would  be  using  only 

proxy  values,  derived  empirically  from  Kp. 

Rice  provided  a  specific  operational  mode  to  allow  for  this  option  without  having  to 
actually  remove  any  environmental  data  files  from  the  run  directory.  Option  1  in  line  9  of 
Table  15  is  this  option.  It  essentially  turns  off  the  read  statements  in  the  indata  subroutine  for 

everything  but  the  Jkpfik.  This  was  done  because  one  ofthe  original  Air  Force  design 

specifications  for  MSM  was  that  it  had  to  be  robust ,  i.e.  it  had  to  be  capable  of  operation 
even  with  a  catastrophic  loss  of  data  to  the  point  of  being  left  with  Kp  alone  (4:2-7).  This 
option  allows  easy  testing  of  the  model  in  this  mode. 

3.2.2.2.3  Kp  Only  Mode  Using  Default  Model 

In  the  event  of  catastrophic  data  loss  for  the  entire  simulation  period,  another 
alternative  exists  in  MSM.  It  is  option  2  in  line  9  of  Table  15.  This  option  employs  ’default 
models’  (4:2-7).  Although  these  models  are  based  on  Kp  only,  they  must  not  be  confused 
with  the  front-end  routines  described  above.  Default  models  completely  bypass  the  processes 
described  above  in  which  the  front-end  models  play  a  role.  No  proxies  are  determined  for 
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missing  parameter  values.  No  electric  and  magnetic  field  algorithms  are  used.  No  particle 
distribution  fimctions  are  employed.  Instead,  flux  outputs  are  determined  empirically,  directly 
firom  Kp.  These  default  models  are  average  models  and  contain  no  intrinsic  time  dependence 
other  than  that  derived  from  the  variation  in  Kp.  They  totally  replace  MSM  time  dependent 
computed  flux  output. 

3.2.3  Static  Input  Category 

There  are  six  files  in  the  static  input  category.  Table  7  names  the  files  and  gives  an 
overall  description  of  the  input  category,  with  bullets  which  apply  to  all  files.  Since  the  model 
user  is  not  required  to  manipulate  these  files  in  any  way,  no  table  is  presented  with  detailed 
information  on  the  individual  files. 


TABLE? 

OVERALL  DESCRIPTION  OF  STATIC  INPUT  CATEGORY 


File  names:  coord,  dktable ,  efcoef,  hardy ,  ioneng ,  ionnum _ 

-  these  files  are  supplied  with  the  code  and  do  not  change  (static) 

-  they  contain  coefficient  data  used  to  set  up  the  coordinate  grid  of  the  model  or  they 
contain  coefficient  data  used  by  the  front-end  and  default  models  when  gaps  exist  in  the 
environmental  data  files 

-  they  can  be  considered  an  integral  part  of  the  model _ 


3.3  Understanding  MSM  Code 

It  is  not  feasible  to  present  the  details  of  MSM  code  in  this  report.  Instead,  coverage 
is  limited  to  providing  an  overview  of  the  topic.  The  only  details  discussed  in  this  chapter  are 
those  needed  as  background  information  for  understanding  the  issues  and  problems  raised  in 
Chapter  4  or  the  accuracy  results  presented  in  Chapter  5. 
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3,3.1  Overview  of  MSM  Code 


MSM  source  code  is  written  in  Fortran  77.  It  consists  of  a  highly  modularized 
aggregate  of  more  than  10,000  lines,  with  90  program  subroutines.  Seven  major  functional 
areas  exist.  As  a  reference.  Table  8  lists  the  seven  functional  areas  and  the  subroutines 
associated  with  each  one.  That  is  followed  by  Figure  1,  which  provides  a  simplified  flow  chart 
of  the  structure  of  MSM. 


TABLE  8 

CATEGORIZATION  OF  MSM  SUBROUTINES 


MAJOR  FUNCTIONAL  AREA 

SUBROUTINE  NAMES 

Control  Routines 

msmcon  .  pptcon ,  ebcon ,  hiepar 

Magnetic  Field  Model 

btrace ,  bfgyro ,  fndbrk ,  getmat ,  loadbm , 
mexist .  rmvbsh ,  zerobm 

Electric  Field  Model 

efield ,  aurora ,  efbndy ,  efloc ,  emodel , 
epot,fndbnd,  low,  regl ,  thet 

Particle  Tracer  and  Loss  Algorithms 

pptm ,  bndchk ,  bndset ,  cexrat ,  dvefdi  ,rk4 , 
dvefdj  flxcal  ,flxnit  ,flxtrp  ,flxval ,  inital , 
mover ,  opterr ,  rlyons ,  setalm ,  setref  ,tchk , 
setsct,  thrcal,  vlocty ,  vmlset  ,vmnom  ,wkrate 

Input  and  Output  Data  Handling  Routines 

dtachk ,  dtntrp ,  dtxipt ,  indata ,  output , 
pargen ,  smooth ,  stndof 

Utility  Routines 

blockdata ,  etifix ,  flx2et ,  fndbi ,  gSntrp , 
gStrpa ,  grid,  mltset ,  modflx ,  outp ,  pfix , 
rdhdr ,  rdstfl ,  read3d ,  tconv2 ,  tconv3 , 
timinc ,  tnorml ,  usrtim ,  wrtvec 

Front-End  and  Default  Models 

addhdy ,  aurll ,  aurl2s ,  clpdfl ,  dstdfl , 
efun ,  enet,  eqtdfl ,  flxdfl  ,  f sum ,  patdfl , 
pcpdfl ,  regen ,  stndfl ,  tilt 
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Input  Data 


Figure  1.  MSM  Simplified  Flowchart  (4:2-59) 
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3.3.2  Primary  Control  Routine 


The  main  control  routine  in  the  code  is  named  msmcon.  Here  MSM  reads  the  msmin 
and  enchan  files  to  set  its  control  parameters,  including  reading  in  the  desired  times  for 
starting  and  stopping  model  simulation.  As  mentioned  earlier,  the  model  has  a  nominal  fifteen 
minute  time  step.  The  highest  number  of  consecutive  smiulations  allowed  in  any  contiguous 
computer  run  is  fixed  in  mstncon  at  fifty.  Hence,  a  maximum  limit  of  twelve  hours  of  model 
simulation  is  possible  for  any  single  computer  run. 

At  the  start  time  tag,  the  model  establishes  the  initial  particle  distribution  fimction 
using  the  default  models.  This  is  termed  a  cold  start.  During  a  contiguous  computer  run,  the 
particle  flux  simulations  at  each  of  the  subsequent  steps  use  the  particle  distribution  results  of 
the  previous  step  as  beginning  conditions.  The  original  conditions  set  at  the  start  time  tag  by 
the  default  models  are  not  extremely  accurate,  and  it  takes  several  consecutive  time  steps  to 
wash  out  the  effect  of  the  cold  start.  For  this  reason,  the  first  few  hours  of  model  simulation 
after  a  cold  start  are  not  considered  reliable  (5). 

During  a  contiguous  computer  run,  the  model  automatically  accesses  the  required 
results  of  the  previous  time  step,  proceeding  through  each  fifteen  minute  time  tag  in  the  data 
stream  until  the  one  declared  for  stopping  the  simulation  is  reached.  At  this  point,  model 
execution  ceases.  To  continue  an  uninterrupted  analysis  without  the  introduction  of  a  new  set 
of  cold  start  errors,  a  Tiot  restart'  routine  must  be  accomplished.  Details  on  this  procedure 
will  be  explained  in  the  model  setup  section,  4.2.4. 

3.3.3  IVTagnetic  Field  Model 

The  magnetic  field  routine  in  the  model  is  an  algorithm  flexible  enough  to  represent  a 
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wide  variety  of  magnetospheric  conditions.  Nearly  1000  permutations  of  magnetic  field 
configuration  exist  in  a  350  Mb  lookup  table.  The  model  uses  three  independent 
environmental  input  parameters  to  determine  the  choice  of  magnetic  field  configuration; 

1)  magnetopause  standoff  distance,  2)Dst,  and  3)  Equatorward  edge  of  the  auroral 
boundary. 

MSM  does  not  include  the  effect  of  the  earth's  magnetic  dipole  tilt.  This  means  that 
the  model  has  built  into  it  the  assumption  that  the  magnetic  and  geographic  equatorial  planes 
always  coincide.  This  will  become  a  factor  when  accuracy  testing  is  discussed. 

3.4  Understanding  Output 

MSM  produces  a  set  of  outputs  at  each  fifteen  minute  model  time  step.  Over  the 
course  of  a  run,  they  accumulate  in  twenty  one  files,  mostly  in  a  binary  output  format.  Table  9 
lists  the  names  of  the  output  files  according  to  category. 


TABLE  9 

CATEGORIZATION  OF  MSM  OUTPUT  FILES 


CATEGORY 

FILENAMES 

Particle  Output 

bndloc ,  flux ,  flxbnd ,  hieout ,  ishift ,  vm 

Magnetic  Field  Output 

bmin ,  xmin ,  ymin ,  zmin 

Electric  Field  Output 

V ,  vnorth ,  vsouth 

Auroral  Precipitation  Output 

eavg ,  flxsum ,  ipiflx ,  ipieng 

Utility  Output 

aloct ,  augpar ,  colat ,  errfile 

Many  of  the  files  above  contain  output  results  which  were  not  needed  in  this  study. 
Therefore,  the  only  files  examined  in  detail  in  this  chapter  are  those  which  require  background 
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discussion  for  understanding  issues  raised  in  Chapter  4,  or  accuracy  results  presented  in 
Chapters. 

3.4.1  Output  File  errfile 

An  important  file  for  the  beginning  user  is  the  ertfile  in  the  utihty  category.  MSM  has 
a  significant  array  of  error  trapping  routines.  The  errfile  file  is  the  one  to  which  the  model 
writes  diagnostic  and  informational  output  as  it  executes,  always  in  ASCII  format. 

3.4.2  Output  Files  Used  for  Flux  Studies 

Only  six  of  the  output  files  hsted  in  Table  9  were  needed  for  the  accuracy  studies 
performed.  Model  flux  outputs  are  compared  with  in  situ,  geosynchronous  satellite  flux 
readings.  The  primary  model  output  file  needed  for  this  is  the  fiux  file,  since  it  contains 
differential  flux  values  for  all  model  time  steps  (in  units  of  particles  /  cm^-sec-ster-eV).  MSM 
determines  results  on  a  grid  in  the  magnetic  equatorial  plane.  The  grid  has  62  latitudinal  grid 
lines  and  5 1  longitudinal  grid  lines.  In  order  to  compare  model  outputs  with  in  situ  satellite 
readings,  post-processing  software  is  needed  to  interpolate  MSM  results  to  points  in  space 
along  a  geosynchronous  orbit.  The  model  must  thus  provide  additional  information  to  the 
post-processing  software  to  allow  for  this  interpolation.  The  software  (flxintrp.J)  and 
procedure  for  doing  this  are  discussed  in  Chapter  4.  The  six  files  needed  by  the  interpolation 
software  are  Hsted  in  Table  10. 


TABLE  10 

HLES  NEEDED  FOR  GEOSYNCHRONOUS  FLUX  DETERMINATIONS 


aloct ,  bndloc,  flux ,  xmin ,  ymin ,  zmin 
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3.5  Understanding  Satellite  Comparison  Data 


MSM  satellite  comparison  data  for  this  study  came  from  in  situ  readings  on  two  DoD 
geosynchronous  earth  orbiting  spacecraft,  located  at  15  and  70  degrees  east  longitude. 

Roughly  speaking,  geosynchronous  satellites  orbit  at  6.6  Re  with  the  same  period  as  the  earth, 
remaining  in  the  geographic  equatorial  plane  over  a  single  location  on  the  equator.  Thus,  such 
a  satellite  can  be  considered  to  be  fixed  to  a  given  meridian  as  the  earth  rotates.  Every  1 5 
degrees  of  longitude  equates  to  one  hour  of  planetary  rotation. 

As  mentioned  above,  accuracy  testing  in  this  study  was  performed  through  post¬ 
processing  of  output  files.  It  should  be  mentioned  that  in  situ  geosynchronous  satellite  data 
can  be  optionally  specified  as  input  data  to  MSM  at  run  time.  The  two  files  provided  to  the 
model  must  be  named  epsat,  for  energetic  electron  fluxes,  and  epions,  for  energetic  proton 
fluxes.  If  included  at  model  execution  time,  MSM  uses  the  data  in  subroutine  opterr  to 
perform  a  single  error  analysis  of  model  output.  However,  the  nature  of  this  analysis  was  not 
sufficient  for  the  accuracy  testing  desired  in  this  study.  Rather,  epsat  and  epions  were 
employed  Avith  post-processing  software  discussed  in  the  next  section. 

The  raw  geosynchronous  satellite  data  used  in  this  study  to  verify  MSM  output  fluxes 
was  originally  acquired  by  ETAC,  through  the  Los  Alamos  National  Laboratory  and  Air  Force 
Global  Weather  Central.  AFTT  acquired  it  from  the  ETAC  database. 

The  ETAC  draft  report  indicates  that  the  data  are  five  minute  average  particle  counts 
of  electrons  and  protons  over  broad  kinetic  energy  bands.  The  sensor  look  angle  selected  for 
both  particle  species  was  that  perpendicular  to  the  magnetic  field  lines,  i.e.  the  satellite 
equatorial  direction  (2:7). 
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3.6  Understanding  Post-Processing  Analysis  Software 


The  satellite  data  must  be  converted  from  particle  counts  to  differential  fluxes  to  make 
it  comparable  with  MSM  outputs.  The  last  section  mentioned  that  model  output  must  be 
interpolated  to  geosynchronous  satellite  locations.  It  is  also  necessary  to  perform  ten5)oral 
interpolations  on  the  model  output.  In  addition,  both  sets  may  require  quahty  control  to 
eliminate  anomalous  values. 

Each  such  step  is  manifested  in  a  piece  of  software.  Since  all  these  activities  must  be 
accomplished  subsequent  to,  and  exterior  to  the  MSM  run,  this  report  coins  the  phrase  post¬ 
processing  software"  to  describe  them. 

Tables  1 1, 12  and  13  list  and  define  the  concepts  behind  the  post-processing 
software  used  in  this  study.  Most  of  the  software  was  developed  by  the  Rice  scientists,  or  in 
some  cases,  the  concepts  behind  a  piece  of  code  were  developed  by  them  and  coded  by 
someone  else.  AFTT  acquired  the  software  from  ETAC,  where  minor  modifications  had  been 
made.  Some  programs  were  written  at  ETAC.  One  of  the  programs  is  original  to  AFTT, 
qinng  with  minor  modifications  of  other  programs. 

Table  11  provides  a  synopsis  of  software  used  for  post-processing  of  model  output. 
Table  12  examines  the  software  used  to  process  satelhte  comparison  data  from  its  raw  form  to 
one  which  is  comparable  to  model  output.  Table  13  explains  the  concepts  behind  the  software 
used  to  actually  calculate  the  RMS  error  of  the  model.  The  detailed  description  of  these 
algorithms  and  the  issues  related  to  them  are  explained  in  Chapter  4. 
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TABLE  11 

POST-PROCESSING  SOFTWARE  USED  WITH  MSM  OUTPUT 


*  A  '15'  or  '70'  in  a  filename  indicates  the  file  contains  model  output  interpolated  to  the  orbit 
positions  of  geosynchronous  satellites  located  at  15  and  70  degrees  east  longitude, 
respectively. 

**  A  lowercase  'x'  in  a  filename  refers  to  a  generic  run  prefix  identifier,  and  an  uppercase  'X' 
refers  to  the  Kp  data  mode,  both  declared  in  the  msmin  file  (see  Table  15).  An  'ele'  indicates 
the  file  contains  electron  output,  and  an  'ion'  indicates  it  contains  proton  output. 
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TABLE  12 

POST-PROCESSING  SOFTWARE  USED  WITH  SATELLITE  COMPARISON  DATA 


PROGRAM 

NAME 

DESCRIPTION 

INPUTS 

NEEDED 

OUTPUTS 

YIELDED 

epform.f 

-this  software  takes  original  geosynchro¬ 
nous  satelhte  files  and  reformats  appropri¬ 
ately  for  use  by  the  epconv./ software 
-units  of  the  data  at  this  point  are 
(particles  /  cm^-sec-ster-MeV) 

-this  program  was  written  by  ETAC 

original 
geosyn¬ 
chronous 
satellite 
flux  files 

epsat.orig* 

epions.orig 

epconv.f 

-this  software  takes  the  satellite  data  files 
and  performs  five  operations: 

1)  initial  quahty  control 

2)  sensor  deadtime  correction 

3)  differential  energy  channel  calculations 
(convert  particle  coxmts  to  differential  flux) 

4)  applies  channel  correction  factors 

5)  reformats  to  Rice  format  *** 

-units  of  the  data  at  this  point: 
logio  (particles  /  cm^-sec-ster-keV) 

-Rice  developed  the  algorithms,  the 
program  was  coded  by  ETAC,  minor 
modifications  and  corrections  by  AFTT 

epsat.orig 

epions.orig 

epsat.rev** 

epions.rev 

epqc.f 

-this  software  takes  the  Rice  format  satel¬ 
lite  data  and  performs  three  operations: 

1)  final  quahty  control 

2)  divides  the  data  into  separate  files  for 
each  satelhte  location  and  particle  type 

3)  reformats  data  for  use  by  compare./ 

-this  program  was  written  by  ETAC, 
modified  by  AFIT 

epsat.rev 

epion.rev 

epqcelelS**** 

epqcionlS 

epqcelelO 

epqcionJO 

*  An  'ep'  in  the  filename  stands  for  'energetic  particles’,  while  'orig'  stands  for  'original  data.' 

**  A  'sat'  in  the  filename  indicates  the  file  contains  electron  data,  while  'ions'  indicates  the  file 
contains  proton  data,  and  'rev'  stands  for  'revised  data.’ 

***  A  Rice  format  indicates  that  the  files  are  ready  for  direct  model  input,  for  use  in  opterr 
subroutine  error  analysis  (see  Section  3.5).  The  opterr  method  was  not  used  at  AFIT. 

****  A  'qc'  in  the  filename  indicates  the  data  in  the  files  is  in  its  final  quality  controlled  form. 
A  '15'  or  '70'  in  these  filenames  indicates  that  the  data  originated  fi-om  geosynchronous 
satellites  located  at  15  and  70  degrees  east  longitude,  respectively. 


TABLE  13 

POST-PROCESSING  SOFTWARE  USED  TO  PERFORM  RMS  ERROR  ANALYSIS 


PROGRAM 

NAME 

DESCRIPTION 

INPUTS 

NEEDED 

OUTPUTS 

YIELDED 

compare./ 

-this  software  compares  modified  MSM 

xXflial5.ele 

xXerrele.15* 

output  fluxes  with  the  modified  in  situ 

xXfluxlS.ion 

xXerrion.15 

particle  fluxes  and  calculates  the  squared 

xXfluxJO.ele 

xXerrele.  70 

difference  between  the  two 
-this  program  was  written  at  AFIT 

Basic  Methodoloav** 

-in  situ  readings  are  at  five  minute 
intervals  and  MSM  output  is  at  fifteen 
minute  intervals 

-temporal  interpolations  are  performed 
between  neighboring  MSM  flux  values  to 
create  values  with  time  tags  which  match 
the  in  situ  flux  time  tags 
-the  squared  error  is  calculated  between 
the  two  values  at  each  time  step*** 

xXfluxJO.ion 

epqcelelS 

epqcionlS 

epqceleJO 

epqcionJO 

xXetrion.  70 

*  The  'err'  in  the  filename  indicates  that  these  files  contain  the  error  calculations  for  the  model 
run,  as  compared  to  in  situ  satellite  data. 

**  The  methods  employed  in  all  the  software  listed  in  Tables  11,12  and  13  will  be  revisited, 
and  fully  explained  in  Chapter  4. 

***  A  separate  file  is  output  for  each  particle  species  and  satellite  location.  Every  file 
contains  the  results  for  all  three  energies  studied  for  each  particle  species.  For  each  energy 
studied,  model  flux,  in  situ  flux  and  squared  error  are  listed  for  each  five  minute  time  step. 


3.7  Understanding  Miscellaneous  Utility  Software 

Several  small  computer  programs  are  needed  for  various  utility  purposes  in  the 
complex  process  of  completing  an  MSM  accuracy  analysis.  These  are  in  addition  to  the 
pieces  of  software  already  mentioned  in  this  report.  Table  14  below  summarizes  them.  Each 
piece  of  miscellaneous  utility  software  is  completely  separate  from  the  MSM  code,  and  must 
not  be  confused  with  the  utility  subroutines  listed  in  Table  8. 
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TABLE  14 

MISCELLANEOUS  UTILITY  SOFTWARE 


PROGRAM  NAME 

DESCRIPTION 

fixfiles.f 

-reads  in  the  MSM  output  flia  file  and  rewrites  only  the  most  recent 
record  for  use  in  a  hot  restart  (to  save  disk  space) 

-resets  msmin  file  times  to  run  the  model  for  the  next  12  hour  period 
-updates  the  sumkp  file  and  sun  spot  number  every  24  hours 
-written  by  ETAC  using  Rice  concepts,  minor  modifications  by  AFIT 

runmsm 

-automatically  executes  the  MSM  model  in  backgroimd  mode  for  a 
declared  number  of  consecutive,  contiguous  runs,  initiating  the 
necessary  post-processing  programs,  utility  programs,  and  hot  restart 
procedures  required  between  runs 
-written  by  ETAC 

convert/ 

-takes  pep  and  xipatt  input  data  files  received  from  the  University  of 
Texas  at  Dallas  and  reformats  them  for  proper  reading  by  MSM 
-written  by  AFIT 

dstmsm.f 

-takes  dst  input  data  as  received  from  national  archival  source 
(particular  format)  and  reformats  it  for  proper  reading  by  MSM* 

kpmsm.f 

-takes  fkp  input  data  as  received  from  national  archival  source 
(particular  format)  and  reformats  it  for  proper  reading  by  MSM* 

*  These  programs  were  written  by  R.  Hihner,  a  former  Rice  doctoral  student,  now  at  PL. 


3.8  Chapter  Summary 

This  chapter  was  written  to  facilitate  a  working  understanding  of  the  MSM  code  and 
its  related  inputs,  outputs,  and  corollary  software.  A  myriad  of  names  and  concepts  have  been 
introduced,  hi  the  complex  process  of  setting  up  a  testing  platform  for  the  model,  it  is  evident 
that  many  opportunities  would  arise  for  introducing  errors.  The  next  chapter  thoroughly 
explores  such  issues  and  presents  the  solutions  implemented  in  this  study  to  resolve  them. 
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4.  ISSUES  CONFRONTED  FN  BUILDING  AN  MSM  TESTING  PLATFORM 


4.1  Background 

The  last  chapter  presented  information  designed  to  develop  a  conceptual,  working 
understanding  of  the  Magnetospheric  Specification  Model.  This  chapter  presents  potential 
sources  of  error,  a  host  of  technical  issues  encountered,  which  must  be  laid  to  rest  before  one 
can  unambiguously  claim  to  have  established  a  vahd  platform  for  accuracy  testing  of  the 
model.  Only  then  are  the  accuracy  studies  presented  in  Chapter  5  credible.  In  the  end,  given 
the  limits  of  time  and  resources,  certain  assumptions  are  made.  The  goal  is  to  limit  these  to 
defensible  assumptions.  AU  assumptions  remaining  as  a  part  of  this  study  are  clearly  stated. 

The  order  of  presentation  in  this  chapter  will  roughly  follow  that  of  the  last  chapter. 
Topics  covered  will  be  the  issues,  problems  and  solutions  surrounding  the  following: 

1)  input  data,  2)  MSM  code,  3)  output  data,  4)  satellite  comparison  data,  and  5)  post¬ 
processing  analysis  software.  However,  before  proceeding  to  those  topics,  it  is  essential  to 
provide  the  technical  information  needed  to  set  up  and  execute  a  model  run. 

4.2  Model  Setup  and  Execution 

The  MSM  source  code  was  given  the  name  msmwork.f  in  this  study.  This  obviously 
must  be  compiled  to  obtam  executable  code,  called  msmwork  in  this  study.  Actually,  due  to 
the  length  of  the  code  and  the  number  of  subroutines,  it  is  highly  recommended  that  the 
source  code  be  split  into  all  its  various  parts,  each  part  taking  a  subroutine./  name 
convention,  with  compiling  accomplished  usmg  a  Makefile.  In  the  SUN  UNIX  environment, 
such  splitting  is  trivial  using  a  built  in  'spht'  command.  This  procedure  results  in  reduced  time 
spent  compiling,  when  small  adjustments  are  made  to  particular  parts  of  the  source  code. 
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All  input  files  must  be  placed  in  the  same  directory  as  the  executable  code.  This 
includes  all  three  types  referred  to  previously:  operator  specified,  environmental,  and  static 
inputs. 

It  is  useful  to  review  the  details  of  Table  3  at  this  juncture.  Two  operator  specified 
input  files  introduced  there  must  be  created  by  the  user:  the  msmin  file  and  the  enchan  file. 
The  next  two  sections  present  the  mechamcs  of  constructing  them. 

4.2.1  Setup  of  Operator  Specified  File  msmin 

The  msmin  file  has  nine  lines.  Table  15  below  gives  an  example  of  the  content  of  such 
a  file,  and  describes  each  line.  The  narrative  in  this  section  provides  the  detailed  information 


TABLE  15 

SAMPLE  msminVYLE 


LINE# 

SAMPLE 

CONTENT 

DESCRIPTION 

1 

1989  244  86400 

model  start  time:  year,  Juhan  day,  time  (seconds) 

2 

1989  245  43200 

model  stop  time:  year,  Julian  day,  time  (seconds) 

.  3 

1 

cold  start  or  hot  restart  toggle:  0=cold,  l=hot 

4 

'  MSM  run  one ' 

character  identification  for  this  run,  up  to  80  characters 

5 

145.0 

daily  sunspot  number 

6 

'a' 

file  prefix  identification  for  this  run 

7 

0 

ASCII  printout  control  toggle:  0=no  print,  l=print 

8 

1.00 

pep  correction  factor:  1.34=old  SSIES  algorithm, 

1 .0=new  SSIES  algorithm  (see  reference  10) 

9 

0 

environmental  data  input  mode:  0=use  Kp  plus  all  data 
available,  l=use  Kp  only  with  fi’ont-end  models,  2=use  Kp 
only  with  default  models  (see  Section  3. 2.2.2) 
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needed  to  understand  and  setup  this  file. 

Lines  1  and  2  are  such  that  a  12  hour  run  wiU  be  accomphshed  (49  time  steps 
including  the  initial  one).  This  is  standard.  After  each  run  this  must  be  incremented  by  12 
hours  (43200  seconds)  to  set  up  for  the  next  contiguous  run.  This  change  is  one  of  the 
automation  details  acconqjlished  by  the  fixfiles.f  program  between  runs. 

Line  3  is  set  to  0  for  the  initial  run  (the  cold  start).  The y?xy?/es./program  changes  this 
to  1  (and  maintains  it  at  1)  for  all  subsequent  runs  (hot  restarts).  This  teUs  the  model  to  read 
record  number  1  of  the/Ztcc  file  as  the  particle  distribution  starting  point  for  the  next  run.  The 
next  paragraph  explains  how  this  works. 

First,  after  completion  of  a  12  hour  run,  the ^xmPp./program  reads  in  the  values  at  all 
grid  points  at  the  all  49  time  steps  in  the  flux  file.  It  also  reads  in  the  five  other  necessary 
binary  output  files  discussed  in  Table  1 1 .  Using  this  information,  yZxmPp  is  able  to  determine 
the  spatially  interpolated  flux  values  along  the  geosynchronous  orbit  path  for  the  12  hour 
period.  These  results  are  written  to  the  modflux  files.  The  information  in  the  output  files  is 
no  longer  needed,  except  for  the  values  of  the  last  time  step  in  the  flux  file,  which  are 
necessary  for  beginning  conditions  for  the  next  run.  Therefore,  the/ixyi/es./program  reads 
the  last  record  of  the  flux  file  and  saves  it  to  a  file  called  tempflux.  Then  the  runmsm  program 
erases  all  the  output  files,  including  the  flux  file. 

Finally,  the  runmsm  program  renames  tempflux  to  flia.  Thtflux  file  now  has  only 
one  record  in  it.  On  the  hot  restart,  line  3  of  the  msmin  file  instructs  the  model  to  use  this 
record  as  the  particle  distribution  starting  point  file  for  that  run. 

Line  4  can  be  any  character  string  the  user  chooses  for  identification  of  file  headers,  up 
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to  80  characters  in  length.  This  remams  static  throughout  a  series  of  contiguous  runs. 

Line  5  is  the  daily  sunspot  number  (SSN).  The  issue  of  sunspot  number  as  an  input 
requires  some  explanation.  Note  that  SSN  was  not  listed  as  an  input  file  in  the  section  on 
inputs  earlier  in  this  report.  This  is  because  it  is  provided  to  the  model  in  the  msmin  file  rather 
than  via  the  indata  subroutine  like  all  other  input.  Two  methods  exist  for  handling  SSN.  The 
first  method  is  simply  to  take  the  arithmetic  mean  of  the  daily  SSNs  for  the  period  of  interest 
and  enter  it  here  on  line  5  as  a  static  value.  This  was  the  standard  practice  of  the  Rice 
developers  (5).  Alternately,  a  file  of  daily  sunspot  numbers  for  the  period  of  interest  can  be 
created  and  placed  in  the  directory  with  the  executable  code.  The  user  can  then  modify  the 
fixfiles  program  to  update  line  5  with  the  passage  of  each  24  hour  period  m  the  input  data  set. 
This  was  the  approach  adopted  in  this  study.  It  allows  for  flexible  choice  of  data  periods. 

SSN  is  a  required  input.  It  is  available  in  archive  form  fi-om  the  Space  Environmental 
Services  Center,  Boulder,  Colorado.  However,  it  should  be  stated  that  it  is  used  by  the  model 
only  in  the  hiepar  routine.  This  routine  gives  a  crude  estimate  of  high  energy  particle  fluxes 
(greater  than  3  MeV).  The  methodology  of  this  routme  is  entirely  different  firom  that  used  to 
determiue  particle  fluxes  in  the  1-100  keV  energy  range.  It  is  a  simple,  en^irical  method 
rather  than  a  physically  based  method  (4:2-2).  This  study  did  not  look  at  hiepar  outputs. 

Line  6  of  the  msmin  file  simply  assists  the  user  in  bookkeeping.  All  output  files 
produced  during  a  model  run  are  actually  named  as  follows:  the  file  name,  preceded  by  the 
prefix  letter  found  on  line  6.  Thus,  the  model  wouldn't  produce  a  file  named  flux,  but  rather 
a  file  named  aflux,  given  the  case  of  the  example  msmin  file  above.  This  becomes  an  issue 
when  multiple  independent  runs  are  performed. 
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Line  7  is  the  toggle  for  instructing  the  model  whether  or  not  to  exercise  an  option  to 
have  all  output  printed  to  the  screen  (or  routed  to  a  print  file)  in  ASCII  format  as  the  model 
executes.  This  produces  one  long  ASCII  file  as  well  as  all  the  individual  files  named  in  Table 
9.  Since  this  option  slows  down  the  model  run  and  requires  additional  memory,  the  no  print 
option  was  the  default  in  this  study. 

Issues  regarding  line  8  will  be  discussed  later  in  the  chapter.  At  this  juncture,  it  is 
sufficient  to  understand  that  a  value  of  1 .00  or  1 .34  is  needed  on  for  the  model  to  execute. 

Line  9  provides  the  toggle  for  instructing  the  model  on  how  to  handle  the  available 
environmental  input  data.  The  issues  involved  here  were  fully  explained  m  Section  3. 2.2.2. 
4.2.2  Setup  of  the  Operator  Specified  File  enchan 

The  other  user  specified  input  file  besides  msmin  is  the  enchan  file.  The  mechanics  of 
setting  up  the  enchan  file  are  quite  sinq)le,  although  certain  issues  regarding  choice  of  entries 
into  the  file  are  more  complex.  The  mechanics  will  be  described  here,  the  issues  will  be  dealt 
with  later  in  the  chapter. 

Table  1 6  below  gives  an  example  of  the  content  of  an  enchan  file,  and  describes  each 
line.  The  narrative  in  this  section  provides  the  detailed  information  needed  to  understand  and 
setup  the  file. 

The  model  user  determines  the  size  of  the  enchan  file.  Except  for  Line  1,  each  line 
entered  in  the  enchan  file  contains  two  numbers.  The  first  is  an  integer  and  the  second  is  a 
floating  point  number.  The  integer  number  defines  the  chemical  species  the  user  desires  for 
the  model  to  simulate.  The  number  1  is  used  for  electrons,  the  number  2  for  protons,  and 
the  number  3  for  oxygen  ions.  The  floating  point  number  in  each  entry  represents  the 
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TABLE  16 

SAMPLE  enchan  FILE 


LINE# 

SAMPLE 

CONTENT 

DESCRIPTION 

1 

6 

-  the  first  line  tells  the  model  how  many  'energy  channels'  to 
simulate  ('energy  channel'  is  defined  in  the  narrative  below) 

2 

1  37000. 

-  subsequent  lines  define  particle  species  and  energies  (in  eV) 

3 

1  54000. 

4 

1  80000. 

5 

2  56500. 

6 

2  71500. 

7 

2  90000. 

particle  energy  at  which  the  user  desires  for  the  model  to  calculate  differential  flux  outputs. 
The  combination  of  particles  species  and  energy  is  called  an  'energy  channel'  (6:56-57).  A 
TnayinniTn  of  37  energy  channels  are  allowed.  Electron  entries  precede  proton  entries,  and 
proton  entries  precede  oxygen  ion  entries.  Within  a  chemical  species,  energies  must  be  in 
ascending  order. 

Line  1  of  the  enchan  file  simply  records  the  total  number  of  energy  channels  the  user 
desires  for  the  model  to  simulate.  Declaring  this  number  allows  the  model  to  appropriately 
dimension  its  arrays. 

4,2.3  Setup  of  the  Magnetic  Field  Files 

Another  set  of  files  which  must  be  accessible  to  the  executable  code  is  the  set 
containing  the  lookup  table  of  magnetic  field  configurations.  As  mentioned  in  the  previous 
chapter,  there  are  nearly  1000  of  these  files,  requiring  over  350  Mb  of  storage  space.  The 


36 


easiest  means  of  handling  these  files  is  to  place  them  together  in  their  own  subdirectory,  below 
the  home  directory  of  the  MSM  executable  code. 

The  MSM  code  accesses  the  magnetic  field  files  by  OPEN  statements  in  two  different 
subroutines,  loadbm  and  mexist.  The  FORMAT  statement  for  these  is  the  same  in  each 
subroutine,  and  includes  the  pathname  to  the  B-field  files.  The  user  must  make  the  pathname 
here  specific  to  the  file  organization  he  establishes  on  his  machine. 

Additionally,  the  CHARACTER  declaration  at  the  beginning  of  each  subroutine  must 
have  the  correct  length  declared  for  a  file  called filnam  in  the  subroutines.  This  will  account 
for  all  the  keystrokes  in  the  user  specific  pathname  mentioned  above. 

4.2.4  Executing  Hot  Restarts 

It  would  be  useful  at  this  point  to  review  Tables  1 1  and  14  in  Chapter  3.  Table  1 1 
introduced  a  piece  of  post-processing  software  called  flxintrp.f,  and  Table  14  introduced  two 
pieces  of  utility  software  called  fijrfiles.f  and  runmsm.  All  of  these  need  to  be  present  in  the 
MSM  home  directory. 

Two  methods  are  possible  for  hot  restarts.  The  first  is  the  manual  method.  After  the 
12  hour  run  fi^om  a  cold  start  is  completed  and  all  the  output  files  have  been  created,  flxintrp 
must  be  executed.  The  modflux  files  created  by  this  step  must  now  be  moved  to  another 
directory  for  storage  so  that  they  wtU  not  be  overwritten  the  next  tune  this  step  is  taken.  A 
suffix  should  be  added  to  the  names  of  these  files  in  that  directory  in  such  a  way  that  results 
from  each  run  can  be  distinguished.  If  anything  of  significance  is  in  the  etTfile  for  the  run,  that 
file  can  also  be  stored. 

The  fixfiles  software  must  now  be  executed.  When  this  is  complete,  all  output  files 
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need  to  be  deleted,  since  they  require  15  Mb  of  storage  per  run.  The  tempflux  file  created  by 
executing/zxyi/es  must  now  be  renamed  xjlux,  where  'x'  is  the  run  prefix  fi-om  line  6  of  the 
msmin  file.  The  next  12  hour  run  is  now  ready  for  execution  using  the  msmwork  command. 

The  second  method  for  accomphshing  a  hot  restart  is  to  execute  the  runmsm  software 
fi-om  the  beginning  of  a  study.  All  of  the  steps  enumerated  in  the  manual  method  above  are 
accomphshed  by  runmsm.  This  allows  for  a  "walk  away"  model  run.  The  runmsm  software 
will  execute  a  series  often  12  hour  runs,  as  long  as  the  input  data  files  contain  data  to  cover 
the  period.  A  file  called  nohup.out  is  also  created  using  this  method.  This  file  records  the 
start  and  stop  times  of  each  run  in  the  series,  as  well  as  recording  the  contents  of  the  errfile 
for  each  run.  If  a  person  is  familiar  with  the  C  programming  language,  runmsm  can  be 
modified  to  allow  for  a  different  nmnber  of  consecutive  runs. 

4.2.5  Comparison  Run 

In  order  to  help  test  the  efficacy  of  the  model  testing  platform  at  AFTT,  B.  Hausman 
at  Rice  provided  a  "test  package."  It  consisted  of  msmin  and  enchan  files  and  three  hours  of 
environmental  input  data  from  August  1990.  It  also  included  the  binary  output  files  generated 
on  their  platform  at  Rice,  using  the  same  Version  5.0  of  the  MSM  code.  When  run  at  AFTT, 
the  flux  results  agreed  with  the  Rice  results  to  the  fifth  decimal  place.  This  test  validated  the 
overall  performance  of  the  code  in  the  AFIT  setting. 

Now  that  the  technical  information  needed  to  set  up  and  execute  a  model  run  has  been 
presented,  it  is  possible  to  move  on  to  the  central  theme  of  this  chapter.  As  mentioned 
already,  the  order  of  presentation  will  be  issues  encountered  and  solutions  formulated 
regarding  the  following:  input  data,  MSM  code,  model  output,  satellite  comparison  data,  and 
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post-processing  software. 

4.3  Input  Data  Issues 

4.3.1  Operator  Specified  Input 

The  operator  specified  input  fi[les,  msmin  and  enchan,  have  already  been  discussed  at 
the  conceptual  level  and  in  the  context  of  setting  up  for  model  execution.  However,  several 
issues  remain  to  be  dealt  with. 

4.3. 1.1  msmin  File  Issues 

The  MSM  code,  in  its  delivery  form  from  Rice,  is  written  such  that  the  data  contained 
in  the  msmin  file  must  be  typed  in  through  the  keyboard.  In  the  msmcon  routine,  the  READ 
statements  for  operator  specified  input  are  directed  to  logical  unit  5  (keyboard  default). 
Placing  this  data  in  a  file  allows  for  automation  of  the  run  process.  Therefore,  the  logical  imit 
was  changed  from  5  to  2  in  msmcon  to  allow  use  of  the  msmin  file. 

4.3. 1.2  enchan  File  Issues 

Section  4.2.2  explained  how  to  specify  in  the  enchan  file  the  energy  channels  desired 
for  model  differential  flux  output.  When  doing  an  accuracy  study,  specific  energy  channels 
must  be  chosen.  They  must  correspond  to  particle  species  and  energies  available  in  a  satellite 
data  set.  Otherwise,  no  comparisons  are  possible. 

To  understand  how  satellite  data  is  made  compatible  with  the  model's  differential  flux 
output,  the  issue  of  differential  channel  correction  of  sateUite  data  must  be  explained.  This 
will  be  done  in  Section  4.6.2.3.  At  this  juncture,  it  is  sufficient  to  state  that  the  energy 
channel  values  placed  in  the  enchan  file  are  selected  to  be  the  center  values  of  the  narrowed 
energy  bands  of  the  geosynchronous  satellite  data. 
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4.3.2  Environmental  Input 
4.3.2. 1  Data  Quality  Issues 


The  output  of  any  model  can  only  be  as  good  as  the  inputs  provided.  Acquiring  raw 
environmental  data  sets  and  properly  constructing  model  input  files  from  them  is  a  non-trivial 
task  in  the  research  effort.  Great  attention  to  detail  is  essential  at  this  juncture.  The 
remainder  of  this  section  will  explore  the  issues  which  must  be  accounted  for  when  setting  up 
the  environmental  data  input  files.  These  issues  were  uncovered  one  by  one  in  the  process  of 
validating  the  data  set  used  in  this  study.  For  some  issues,  no  written  guidance  was  available. 
In  these  cases,  present  and  former  Rice  scientists  and  students  provided  valuable  counsel. 

There  are  two  reasons  for  including  these  details  in  this  report.  First,  proper 
resolution  of  these  issues  is  essential  to  being  able  to  demonstrate  the  validity  of  the  accuracy 
testing  done.  As  mentioned  in  Chapter  2,  difficulties  existed  in  ETACs  original  study,  since 
the  accuracy  of  their  draft  report  was  questionable  due  to  an  inadvertent  mishandling  of  input 
data.  The  second  reason  for  presenting  these  issues  is  that  in  any  future  MSM  research,  a  new 
time  frame  suggested  for  analysis  will  require  the  construction  of  a  new  input  data  set,  and  aU 
these  issues  will  have  to  be  revisited. 

4.3.2. 2  Formatting  Issues 

All  the  environmental  data  files  are  numeric  data  accessed  by  MSM  through  the 
subroutine  indata.  The  READ  statement  in  indata  is  an  unformatted  read.  Thus,  there  are 
only  three  sin5)le  guides  on  formatting.  The  first  point  is  that  the  files  must  contain  seven 
columns  in  each  row,  each  row  corresponding  to  a  given  time  tag.  Secondly,  the  first  three 
columns  must  correspond  to  1)  parameter  value,  2)  year,  and  3)  Juhan  decimal  day.  Finally, 


40 


the  last  four  columns  in  each  row  are  place  holders,  given  values  of  -999.  The  number  of 
spaces  between  columns,  and  whether  the  numbers  are  floating  point  or  integer  are  not  critical 
in  unformatted  reads. 

4.3.2. 3  fkp  File  Issues 

The  Gottingen  Kp  data,  as  archived  by  the  National  Geophysics  Data  Center  (NGDC), 
comes  as  eight,  three  hour  values  per  day.  The  first  value  applies  from  0000-0300  Z,  the 
second  from  0300-0600  Z,  etc.  The  NGDC  files  list  the  standard "+,  o,  -  descriptors  in  a 
decimal  format.  For  example,  a  Kp  index  of  "4-"  is  listed  as  3.7,  "4o"  is  4.0,  and  "4+"  is  4.3. 

Certain  issues  must  be  taken  into  account  with  Kp  data.  These  relate  to  the  way  the 
Kp  values  must  be  rendered  in  the  input  file.  First,  it  must  be  highlighted  that  for  Kp  (and  for 
most  input  parameters),  the  time  increment  between  data  points  is  much  longer  than  the 
model's  15  minute  time  step.  Thus,  the  model  must  interpolate  between  two  data  values  to 
establish  input  values  for  the  intervening  time  steps. 

If  Kp  values  were  simply  placed  in  the  input  file  at  each  three  hour  mark,  then  the 
model  would  interpolate  between  the  three  hour  values  and  produce  a  continuously  sloping 
Kp  input.  Kp  is  intended  to  be  constant  for  a  three  hour  period  in  the  model,  since  it  is  a 
three  hour  index  (5).  To  model  a  constant  value  for  a  three  hour  period,  the  same  value 
would  have  to  be  designated  at  both  ends  of  the  period.  However,  a  difficulty  would  be 
encountered  with  the  change-over  points  at  the  three  hour  marks.  Here  the  model  would  see 
a  step  fimction  Avith  an  infinite  slope,  and  it  could  not  handle  this  mathematically. 

As  a  consequence,  the  Rice  developers  devised  a  thirty  minute  'ramp  concept  around 
the  three  hour  marks  (5).  To  understand  this,  suppose  the  NGDC  Kp  data  file  showed  the 
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following  values  for  Julian  day  244  of  1989:  2.3  for  0000-0300  Z,  2.0  for  0300-0600  Z,  and 
0.7  for  0600-0900  Z.  In  the  fkp  file,  the  values  would  be  rendered  as  shown  in  Figure  2. 
Figure  3  then  shows  the  idea  graphically. 


2.3 

1989.0 

244.0104 

-999 

-999 

-999 

-999 

2.3 

1989.0 

244.1146 

-999 

-999 

-999 

-999 

2.0 

1989.0 

244.1354 

-999 

-999 

-999 

-999 

2.0 

1989.0 

244.2396 

-999 

-999 

-999 

-999 

0.7 

1989.0 

244.2604 

-999 

-999 

-999 

-999 

0.7 

1989.0 

244.3646 

-999 

-999 

-999 

-999 

Figure  1:  Sample  Jkp  File 


Figure  3.  Sample  Jkp  File  Data  Plot 
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The  Kp  values  are  assigned  at  15  minutes  after  a  three  hour  mark,  and  15  minutes 
before  the  next  three  hour  mark.  In  Figure  2,  if  we  translate  fi'om  decimal  day  format 
(multiply  the  fractional  part  by  1440  to  get  the  number  of  minutes),  we  see  that  the  0000-0300 
Z  value  of  2.3  is  time  tagged  at  the  001 5  Z  mark  and  again  at  the  0245  Z  mark.  Then,  the 
0300-0600  Z  value  of  2.0  is  time  tagged  at  the  03 1 5  Z  mark  and  again  at  the  0545  Z  mark, 
etc.  Thus,  the  model  interprets  the  Kp  value  as  flat  for  two  and  one  half  hours.  Then,  for  one 
half  hour  across  each  three  hour  mark,  there  is  a  ramp,  or  slope,  to  the  next  Kp  value. 

The  fkp  file  originally  acquired  from  ETAC’s  study  was  discarded  as  faulty  in  this 
study  due  to  various  formatting  issues  of  the  types  described  above.  ETAC  subsequently 
provided  an  updated  file  for  use  in  the  AFTT  study.  It  was  important  to  independently  verify 
that  it  was  correct.  Therefore,  the  data  in  the  file  were  manually  conq)ared  against  original 
data  acquired  from  the  NGDC  database  for  the  period.  Both  the  ^  values,  and  the  way  in 
which  they  were  rendered  in  the  data  file  were  correct. 

4.3.2.4  dst  File  Issues 

The  NGDC  data  files  present  Dst  values  as  24  numbers  per  day.  The  first  number  in 
the  data  file  applies  to  the  first  hour  of  the  day,  0000-0100  Z,  the  second  niunber  applies  to 
0100-0200  Z,  etc.  The  Rice  developers  determined  that  the  best  way  to  render  this  in  an  input 
file  was  to  give  the  data  a  half  hour  time  lag,  that  is,  assign  the  index  value  for  a  given  hour  to 
the  half  hour  time  tag  of  that  hour  (5).  Thus,  the  0000-0100  Z  value  gets  assigned  to  0030  Z, 
etc. 

This  brings  up  a  potential  stumbling  block  which  presents  itself  when  translating  data 
from  archived  sources  into  input  files.  This  problem  is  present  any  time  the  values  in  the 
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archived  source  are  an  index  (over  a  given  number  of  hours),  or  are  averages  of  measurements 
over  a  certain  time  period,  as  opposed  to  being  an  environmental  reading  at  a  discrete  point  in 
time.  Two  issues  must  be  carefiilly  taken  into  accoimt  in  these  cases. 

First,  with  respect  to  the  archived  data  source,  an  hourly  parameter  such  as  Dst  may 
sometimes  be  time  tagged  at  hours  0  through  23  of  the  day,  or  perhaps  in  a  different  source  at 
hours  1  through  24  of  the  day.  It  must  be  determined  if  a  time  tag  of  indicates  that  the 
value  apphes  from  0000-0100  Z,  or  from  0100-0200  Z,  etc.  Is  it  a  'before'  or  an  'after'  time 
tag?  For  Kp,  would  a  value  time  tagged  in  the  archived  data  at  0300  Z  apply  from  0000- 
0300  Z,  or  from  0300-0600  Z?  The  documentation  provided  with  the  archived  data  should 
provide  the  answer,  and  must  be  carefully  followed. 

Secondly,  when  translating  the  values  to  an  input  file,  consideration  must  be  given  to 
how  the  model  reads  the  data.  An  example  of  this  is  how  Kp  was  'ranged'.  In  the  case  of 
Dst,  an  on  the  hour  value  was  assigned  to  the  next  half  hour  time  tag  (assuming  a  tjefore  time 
tag  in  the  archived  data).  This  means  that  for  Dst,  the  model  continuously  interpolates 
between  values  at  hour  centers. 

As  in  the  case  of  the  Kp  data,  it  was  important  to  independently  establish  that  the  dst 
file  acquired  for  this  study  was  sound.  The  data  in  the  file  were  manually  compared  against 
original  data  acquired  from  the  NGDC  database.  Both  the  Dst  values,  and  the  way  in  which 
they  were  rendered  in  the  dst  file  were  correct. 

4.3.2.5  eqedee  File  Issues 

This  data  is  a  derived  data  set,  taken  from  raw  DMSP  SS  J/4  sensor  readings,  then 
processed  at  Phillips  Lab  (PL).  It  is  usually  approximately  an  hourly  value,  often  having  a 
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more  frequent  interval.  No  adjustment  is  needed  to  the  time  tags  of  the  data  values  when  they 
are  rendered  in  the  input  files  (5). 

In  this  study,  eqedge  data  was  assumed  to  be  valid  and  accurate  as  received  from 
ETAC,  since  it  originated  at  PL.  No  attempt  was  made  to  assimilate  or  question  the 
algorithm  applied  to  the  raw  data,  or  to  pursue  an  understanding  of  the  satellite  sensor. 

This  file,  eqedge,  and  the  next  two  discussed,  pep  and  xipatt,  are  all  derived  from  raw 
satellite  data  and  can  have  a  fairly  high  data  density  (number  of  values  per  time  unit).  When 
setting  up  inputs  for  a  simulation  period  of  one  month  or  more,  the  number  of  entries  in  these 
files  can  easily  exceed  the  model's  upper  limit  of  1 500  values  for  data  arrays.  Since  this  study 
used  a  data  set  covering  aU  of  September  and  October  of  1989,  these  three  files  had  to  be  split 
into  halves  covering  one  month.  In  a  long  contiguous  run,  when  the  execution  reaches  the 
crossover  between  months,  some  filename  changes  must  be  made  to  keep  a  continuous  data 
supply  in  place. 

4. 3.2.6  pep  and  xipatt  File  Issues 

The  data  in  these  files  are  derived  from  DMSP  SSBES  sensor  readings,  processed  at 
the  University  of  Texas  at  Dallas  (UTD).  As  in  the  case  of  eqedge  data,  pep  and  xipatt  data 
are  usually  approximately  hourly  values,  sometimes  more  frequent.  No  adjustment  is  needed 
to  the  time  tags  of  the  data  values  when  they  are  placed  in  input  files  (5). 

The  pep  and  xipatt  files  originally  acquired  through  ETAC  were  not  used  in  this 
study.  Instead,  new  data  were  acquired  directly  from  UTD  and  formatted  into  input  files. 

The  reasons  for  this  are  explained  in  the  next  few  paragraphs.  The  new  data  were  assumed  to 
be  valid  and  accurate  as  received  from  UTD.  No  attempt  was  made  to  assimilate  or  question 
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the  algorithms  applied  to  the  raw  data,  or  to  pursue  an  understanding  of  the  satellite  sensor. 

It  was  desired  that  the  newest  version  of  all  items  be  used  in  this  study.  Since  the 
time  of  ET AC’s  study,  the  algorithm  used  at  UTD  to  produce  this  data  has  been  updated. 
Therefore,  new  pep  and  xipatt  data  were  acquired. 

Comments  in  the  MSM  source  code  give  instructions  that  if  new  pep  data  is  used  in  a 
model  run,  Line  8  of  the  msmin  file  must  contain  the  value  1 .00  (4:msmcon-l).  It  must 
contain  the  value  1 .34  if  pep  data  derived  by  the  old  algorithm  is  used.  (See  also  Table  15  of 
this  report.) 

Finally,  some  readers  may  be  aware  of  an  issue  regarding  time  tagging  of  data  fi’om 
DMSP  with  respect  to  equatorial  crossing  times  of  the  satellite  (10).  It  is  sufficient  to  report 
here  that  the  updated  algorithm  used  to  create  the  new  files  for  this  study  treated  this  timing 
issue  in  the  same  way  as  the  old  algorithm  (7).  Thus,  the  new  data  properly  matches  the  built- 
in  timing  correction  in  MSM. 

4.3.2.7  swden  &  swvel  File  Issues 

The  solar  wind  density  and  velocity  data  obtained  through  ETAC  were  used  'as  is'  for 
the  model  rims  in  this  study.  The  ETAC  draft  report  indicates  that  they  obtained  the  data 
from  the  National  Space  Science  Data  Center  (NSSDC)  (2:6).  As  such,  the  data  itself  was 
assumed  to  be  reliable. 

The  data  are  one  hour  averages  given  at  one  hour  intervals.  As  to  temporal  format, 
when  they  were  rendered  in  the  input  files  by  ETAC,  no  half  hour  time  delay  was  used  as  it 
was  in  the  case  of  the  dst  files.  Instead,  the  data  were  time  tagged  at  the  beginning  of  the  hour 
to  which  they  applied  as  an  average.  This  raised  questions.  Therefore,  the  files  were 
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compared  to  test  file  set  acquired  from  Rice,  which  they  had  formatted.  With  respect  to  this 
time  formatting  issue,  the  two  sets  matched  identically.  This  indicates  the  time  tagging  of  the 
solar  wind  files  in  this  study  is  correct. 

Another  question  surfaced  about  these  files  after  the  completion  of  all  model  runs.  It 
was  discovered  that  the  values  in  the  files  do  not  precisely  match  a  current  NSSDC  data  set 
for  the  same  satellite  (IMP-8),  same  parameters  (solar  wind  density  and  velocity),  same  time 
period  (1989,  Julian  days  244-304).  Density  values  differ  by  an  average  of  roughly  five 

percent,  and  velocity  values  by  two  percent. 

The  differences  do  not  appear  to  be  caused  by  a  mishandling  of  the  data  files  by 
ETAC.  Mishandling  would  have  caused  a  systematic  discrepancy  such  as  a  time  shift  due  to  a 
missing  data  value,  and  this  would  have  been  obvious.  The  discrepancies  between  values  in 
the  two  files  are  tiny,  random  differences  at  nearly  every  time  step.  Encouragingly,  the  two 
data  sets  show  identical  dynamical  patterns  over  the  long  run. 

The  NSSDC  data  files  may  have  simply  been  updated  since  the  time  ETAC  acquired 
the  data  from  them  several  years  ago.  It  seetos  logical  that  the  current  data  sets  may  be  the 
product  of  new  NSSDC  algorithms  used  to  determine  solar  wind  density  and  velocity. 

In  the  final  analysis,  the  differences  between  the  data  sets  are  small  enough  that  the 
effects  on  MSM  outputs  are  assumed  to  be  minor.  However,  no  unambiguous  answer  has  yet 
been  obtained  to  the  above  issue.  Therefore,  consideration  was  given  to  excluding  from  this 
report  any  model  output  results  which  included  as  inputs  the  solar  wind  data.  However,  it 
seems  to  be  a  sensible  assumption  that  the  solar  wind  inputs  are  rehable,  though  shghtly  dated, 
and  results  derived  using  them  as  inputs  provide  useful  information  about  the  performance  of 
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the  model.  Therefore,  the  decision  was  made  to  retain  these  results  in  this  report.  In  the 
analyses  performed  in  this  study,  many  of  the  model  runs  were  performed  without  solar  wind 
data  as  inputs.  Those  which  include  it  will  be  easily  identified. 

4.4  MSM  Code  Issues 

4.4.1  Compiler  Issues 

Two  compiler  issues  surfaced  in  this  research  effort.  The  first  was  previously  reported 
in  the  ETAC  draft  report  (2:16).  In  the  delivered  MSM  code,  there  exists  a  subroutine  named 
grid  as  well  as  a  COMMON  block  with  the  same  name.  The  SPARC  2  SUN  Fortran  compiler 
would  not  compile  because  of  this  name  duphcation.  Since  there  are  only  two  calls  to  the 
subroutine,  but  many  occurrences  of  the  COMMON  block,  the  most  expedient  fix  was  to 
change  the  name  of  the  subroutine  from,  grid  to  rgrid. 

The  second  conqjiler  issue  had  to  do  with  Fortran  conopiler  version.  The  original 
Fortran  version  on  the  SPARC  2  workstation  used  in  this  study  was  Fortran  1 .3.  Inexplicable 
compiler  errors  occurred  using  this  version.  A  simple  switch  to  Fortran  1 .4  resulted  in  a 
complete  resolution  of  the  situation,  with  no  change  in  the  MSM  source  code.  It  is  beheved  in 
hindsight  that  the  problem  lies  in  the  way  in  which  the  older  Fortran  compiler  handles  memory 
allocation  (static  vs.  dynamic).  It  could  be  that  a  ’static'  option  declared  in  the  con^iling  step 
might  allow  the  use  of  Fortran  1 .3  with  MSM  code  on  the  SPARC  2.  However,  this  was  not 
proven,  and  it  is  suggested  that  Fortran  1 .4  or  later  be  used  to  compile  the  source  code. 

4.4.2  Run  Time  Comparison 

MSM  is  very  computationally  intensive.  Therefore,  a  comparison  of  performance 
speeds  between  different  computer  platforms  may  be  useful  to  a  future  researcher.  The 
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statistics  in  the  following  table  are  derived  from  executions  of  the  model  on  five  different 
UNIX  machines,  each  with  the  identical  one  hour's  worth  of  input  data.  Since  it  was  not 
possible  to  get  dedicated  use  of  most  of  the  machines,  the  percent  of  the  dedicated  CPU  time 
in  each  case  varies.  This  table  is  provided  as  a  qualitative  tool  only.  No  claim  of 
determination  of  absolute  performance  of  these  machines  is  implied.  As  a  rule  of  thumb,  the 
most  significant  figures  for  comparison  are  the  CPU  times.  The  lower  the  better.  System 
time  is  related  to  things  like  input  /  output  overhead.  Elapsed  time  (wall  time)  depends 
strongly  on  how  heavily  multi-tasked  the  CPU  was  with  other  users  (look  at  the  percent  of 
total  CPU  time  given  to  the  MSM  taskmg). 


TABLE  17 

MSM  RUN  TIME  COMPARISON 


MACHINE 

CPU  TIME 
(sec) 

ELAPSED 
TIME  (min) 

PERCENT  OF 
TOTAL  CPU 

SPARC  20 

282.3 

5.5 

9:45 

49 

SGI  R3000 

308.9 

51.3 

7:13 

83 

KUBOTA 

,  518.9 

23.9 

9:32 

94 

SPARC  10 

613.8 

38.8 

11:23 

95 

SPARC  2 

684.0 

12.3 

12:18 

94 

The  SPARC  2  was  generally  available  for  dedicated  usage.  A  typical  run  of  12  hours 
of  data  on  this  platform  consistently  required  140  minutes  of  wall  time.  A  five  day,  hands  off 
run  using  mnmsm  required  roughly  24  hours.  By  comparison,  when  a  SPARC  20  was  free  for 
essentially  dedicated  usage,  a  run  of  12  hours  of  data  took  roughly  60  minutes,  and  a  five  day 


49 


run  required  approximately  10  hours. 
4.5  Model  Output  Issues 


The  next  three  major  sections  of  this  chapter,  4.5,  4.6  and  4.7,  are  highly 
interconnected.  The  issues  which  arose  regarding  model  output,  satelhte  comparison  data  and 
post-processing  software  are  difficult  to  separate.  As  a  consequence,  some  topics  are 
presented  out  of  sequence  with  respect  to  section  headings. 

4.5.1  Assumptions  Made  Regarding  Model  Output 

MSM  includes  no  dipole  tilt  in  its  modelling.  Differential  flux  output  in  the  magnetic 
equatorial  plane  is  assumed  to  he  equivalent  to  that  in  the  geographic  equatorial  plane.  This 
built  in  assumption  was  accepted  in  this  study. 

Two  necessary  interpolations  of  output  flux  values  were  performed.  The  fest, 
accomphshed  by  the  flxintrp.f  software,  is  a  spatial  interpolation.  The  second,  accomphshed 
by  the  co/wpure.y  program,  is  a  temporal  interpolation.  Both  will  be  explained  in  detail  in  later 
sections.  It  was  assumed  that  these  interpolations  are  logical  methods  of  bringing  the  model 
data  to  a  place  where  it  is  comparable  to  the  in  situ  satellite  data.  Only  then  can  calculations 
of  the  squared  error  differences  between  the  two  data  files  be  performed. 

4.5.2  Pn.st-Processing  of  Model  Output 

The  model's  direct  output  is  differential  flux  values  with  the  following  characteristics: 
1)  binary  format;  2)  specified  only  at  model  grid  points;  3)  specified  only  at  each  15  minute 
model  time  tag;  4)  units  of  [particles/cm^-sec-ster-eV];  5)  no  quahty  control  has  been 
performed  on  the  data.  This  is  not  an  appropriate  form  for  comparison  with  satelhte  readings. 

Tables  1 1, 12  and  13  in  Chapter  3  introduced  post-processing  software.  To  review. 
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after  a  model  run,  the  user  must  accomplish  post-processing  of  output  data.  In  addition, 
satelhte  data  must  also  be  manipulated  by  software.  The  goal  is  to  perform  quahty  control  on 
each  data  set,  and  modify  them  to  the  point  where  the  units  match,  and  the  data  values  have 
temporal  and  spatial  correlation. 

This  section  will  explain  the  steps  taken  with  each  piece  of  post-processing  software 
used  on  the  model  output.  Table  1 8  traces  the  changes  made  at  each  step  in  data 
manipulation.  Particular  attention  should  be  paid  to  energy  units. 


TABLE  18 

DETAILS  OF  POST-PROCESSING  OF  MODEL  OUTPUT 


STEP  IN  THE  DATA 
MANIPULATION 

UNITS 

METHOD  USED  TO 
CHANGE  DATA 

MSM  binary  output  files 

particles/cm^-sec-ster-eV 

-  these  are  the  units  of 
the  model  output 

flxintrp.f-  1st  operation 

particles/cm^-sec-ster-eV 

-  spatial  interpolation 

flxintrp.f-  2nd  operation 

particles/cm^  -sec-ster-keV 

-  multiply  by  1000  to 
change  units 

flxintrp.f-  3rd  operation 

loglO  (particles/cm^-sec-ster-keV) 

-  take  loglO 

qcmsm.f 

loglO  (particles/cm^-sec-ster-keV) 

-  quahty  control 

The  1st  operation  of  the  /7xznf/p./ software  is  a  spatial  interpolation  of  the  model  s 
output.  At  the  end  of  each  12  hour  run,  flxintrp.frtdAs  in  the  flux  values  at  all  grid  points  at 
the  49  time  steps  in  the  flia  file.  It  then  reads  in  five  other  binary  output  files  discussed  m 
Table  1 1 .  Using  this  information, is  able  to  determine  where  the  sateUite  orbit  would 
fall  within  the  model  grid  at  each  15  minute  time  tag.  Generally,  these  points  do  not  coincide 
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with  grid  points  at  which  the  model  has  assigned  a  flux  value.  Therefore,  flxintrp  performs 
a  linear,  spatial  interpolation  of  flux  values  between  four  neighboring  model  grid  points.  This 
generates  values  at  the  locations  in  space  where  the  geosynchronous  satellite  would  be  in  its 
orbit  at  each  time  tag. 

The  2nd  operation  of flxintrp.f  is  nothing  more  than  multiplying  each  interpolation 
value  by  1000.  This  simply  changes  the  units  from  ( particles  /  cm^  -  sec  -  ster  -  eV  )  to 
( particles  /  crn^  -  sec  -  ster  -  keV  ). 

The  3rd  operation  of  flxintrp. f  takes  the  loglO  of  the  differential  flux  output  values. 

Log  10  values  are  easier  to  compare  and  graph. 

The  flxintrp. f  software  used  at  AFIT  was  an  ETAC  modified  version  of  the 
corresponding  software  used  at  Rice  called  calfh.f.  For  this  study,  the  format  of  flxintrp. f 
output  was  preferable  to  that  of  calflx.f  However,  it  was  important  to  demonstrate  that  the 
modified  software  produced  identical  results  compared  to  the  original  Rice  version. 

Therefore,  both  programs  were  used  to  process  identical  MSM  binary  output  files. 

Agreement  was  achieved  to  the  fifth  place  past  the  decunal. 

In  Table  12,  the  qcmsm.f^ep  was  introduced  Chapter  3.  It  was  mentioned  that 
during  periods  of  high  geomagnetic  activity,  the  model  boundary  can  shrink  to  less  than 
geosynchronous  orbit  distances.  When  this  occurs,  the  flxintrp  software  recognizes  these 
occurrences  and  flags  those  time  steps  with  9.999  flux  values  in  the  modflux  files.  Before 
using  the  compare  software  to  run  accuracy  tests  against  the  in  situ  satellite  data,  these  out  of 
bounds  values  must  be  removed  from  the  modflux  files.  This  is  the  sole  purpose  of  the 
qcmsm.f  software. 
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4.6  Satellite  Comparison  Data  Issues 


4.6.1  Background  Information 

In  Section  3.5,  the  subject  of  understanding  satellite  comparison  data  was  introduced. 
To  review,  the  data  came  from  two  DoD  geosynchronous  orbiting  spacecraft,  at  longitudes  of 
15  and  70  degrees  east.  The  data  are  five  minute  particle  count  averages  for  electrons  and 
protons  at  approximately  five  minute  intervals  over  broad  energy  bins.  The  data  was 
originally  acquired  by  ETAC  through  the  Los  Alamos  National  Laboratory  and  Air  Force 
Global  Weather  Central.  AFIT  acquired  it  from  the  ETAC  database. 

At  each  time  tag,  the  electron  data  file  has  particle  counts  for  the  energy  channels 
0.030  to  0.300,  0.044  to  0.300,  0.064  to  0.300  and  0.095  to  0.300  MeV.  For  protons  the 
channels  are  0.050  to  0.500, 0.063  to  0.500, 0.080  to  0.500  and  0.100  to  0.500  MeV.  It  is 
more  convenient  to  speak  of  these  inkeV  umts,  i.e.  30  to  300  keV,  44  to  300  keV,  etc. 

4.6.2  Satellite  Data  Processing 

The  satellite  data  must  undergo  significant  modification  of  its  original  form  to  make  it 
compatible  with  MSM  flux  outputs.  The  manipulations  of  the  satellite  data  are  more  complex 
than  those  applied  to  the  model  output.  It  would  be  useful  to  review  Table  12  in  Chapter  3 
where  the  basic  concepts  were  introduced.  This  section  will  present  the  details  of  the 
procedures  employed.  Table  19  below  outlines  the  changes  in  the  satellite  data  at  each  step  in 
its  manipulation.  After  the  table,  elaboration  is  provided  on  each  techmque  used.  As  in  the 
last  section,  particular  attention  should  be  paid  to  energy  units. 
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TABLE  19 

DETAILS  OF  SATELLITE  COMPARISON  DATA  PROCESSING 


STEP  IN  THE  DATA 
MANIPULATION 

UNITS 

OF 

DIFFERENTIAL  FLUX 

METHOD  USED 

TO 

CHANGE  DATA 

original  satellite  data 

particles/cm^-sec-ster-MeV 
**broad  energy  channels  (bee)** 

-  these  are  the 
original  units 

epform.f 

particles/cm^-sec-ster-MeV  (bee) 

-  change  data  format 

epconv.f-lsi  operation 

particles/cm^-sec-ster-MeV  (bee) 

-  quality  control 

epconv.f-2nd  operation 

particles/cm^-sec-ster-MeV  (bee) 

-  detector  deadtime 
correction 

epconv.f-7)Td  operation 

particles/  cm^sec-ster-keV 
**narro wed  energy  channels  (nec)** 

-  differential  channel 
correction 

epco«v./-4th  operation 

logl  0(particles/cm^-sec-ster-keV)  (nec) 

-take  logl  0 

epconv.f-Sth  operation 

log  1 0(particles/cm^-sec-ster-keV)  (nec) 

-  change  data  to 

Rice  format 

epqc.f-lst  operation 

logl  0(particles/cm^-sec-ster-keV)  (nec) 

-  quality  control 

epqc.f-lad  operation 

log  1 0(particles/cm^-sec-ster-keV) 
**assigned  to  central  value** 

-  changes  data  to 
compare. f  format 

4.6.2. 1  Preliminary  Processing 

The  epform.f  software  simply  reads  the  data  from  the  original  Los  Alamos  file  and 
writes  it  unaltered  to  a  new  file,  changing  only  the  format  of  the  page.  Normally  this  step 
would  not  be  necessary.  However,  in  this  case  the  data  in  the  original  file  was  in  an  extremely 
unwieldy  two  page  wide  format. 

The  first  operation  of  epconv.f  consists  of  four  quahty  control  measures  designed  by 
ETAC  to  test  the  integrity  of  the  in  situ  data  (2:8).  Errors  often  arise  in  transmission,  or  from 


other  causes,  when  dealing  with  raw  satellite  data.  Each  observation  contains  values  for 
several  energy  channels.  It  is  assumed  that  if  a  value  in  any  of  the  channels  is  bad  for  a  given 
five  minute  interval,  all  the  values  at  that  time  step  ought  to  be  discarded.  The  energy 
channels,  after  all,  essentially  overlap. 

First,  for  each  five  minute  interval  in  a  given  species,  the  program  checks  to  make  sure 
that  all  broader  energy  channels  have  a  higher  flux  value  than  any  narrower  energy  channels. 
For  example,  the  30  to  300  keV  channel  ought  to  contain  more  particle  counts  than  the 
overlapping  44  to  300  keV  channel,  etc.  The  program  discards  aU  observations  which  do  not 
meet  this  test.  Second,  the  program  eliminates  all  values  at  time  steps  which  contain  any 
negative  or  zero  flux  values.  Third,  the  program  tests  to  make  sure  that  adjacent  energy 
channels  do  not  differ  by  large  amounts.  The  threshold  used  is  the  following;  any  broader 
energy  channel  must  contain  not  greater  than  100  times  the  next  narrowest  energy  channel. 
Fourth,  and  last,  the  program  tests  for  any  extreme  flux  values.  Observations  are  discarded  at 
time  steps  which  contain  any  flux  readings  greater  than  or  equal  to  10*^  particles/cm^-sec-ster- 
MeV.  Overall,  roughly  4%  of  the  values  are  discarded  by  these  measures. 

4.6. 2.2  Detector  Deadtime  Correction 

The  second  epconv.f  operation,  the  Detector  Deadtime  Correction,  is  used  to  add 
back  the  number  of  particles  which  have  been  missed  by  the  sensors  between  instrument 
cycles.  The  ETAC  draft  report  references  a  Quarterly  Status  Report  No.  11.  AF  Geophysics 
Laboratory,  as  the  source  for  this  correction  equation  (2:8).  It  takes  the  following  form: 
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(1) 


1  -  / .  3.1  •  10  ’ 

where  f '  is  the  deadtime  corrected  flux,  and  f  is  the  measured  flux  in  (particles  /  cm--sec- 
ster-MeV)-  It  has  a  very  minor  effect,  accounting  for  a  1%  correction  at  most  (2:7). 

4.6.2.3  DiflFerential  Channel  Correction 

The  third  epconv./ operation,  the  Differential  Channel  Correction,  is  the  most 
complex  of  the  satelHte  data  manipulations.  Recall  that  MSM  determines  differential  flux 
values  for  the  energy  channels  declared  in  the  enchan  file.  In  the  satellite  data  there  are  only 
broad  energy  channels.  Since  the  channels  are  essentially  overlapping  measurements  of  a  five 
minute  interval,  a  narrowed  energy  channel  can  be  created  by  subtracting  adjacent  channels. 
For  example,  the  flux  value  for  the  0.044-0.300  MeV  channel  is  subtracted  fi-om  the  flux  value 
for  the  0.030-0.300  MeV  channel  to  yield  the  value  for  the  0.030-0.044  MeV  energy  channel 
(equivalently,  the  30  to  44  keV  channel).  Conceptually  it  is  as  simple  as  that.  The  full 
explanation  is  a  httle  more  involved. 

The  ET  AC  draft  report  references  the  Quarterly  Status  Report  Nq.  H  as  the  source  of 
the  following  formula  for  corrected  differential  flux  (2:8): 

iff'  [  fh  *  .  1  1  *  ^2) 

He  "  (keV) 

Here  the  and  f  V+i  values  are  the  deadtime  corrected  fluxes  for  adjacent  broad  energy 


56 


channels,  in  units  of  (  particles  /  cm"  -  sec  ster  -  MeV  ).  The  AE^  and  AEb+i  are  the  broad 
energy  channel  bandwidths  in  terms  of  (MeV)  units,  i.e.  [  0.300  (MeV)  -  0.030  (MeV)  ]  = 
0.270  (MeV),  and  [  0.300  (MeV)  -  0.044  (MeV)  ]  =  0.256  (MeV),  etc.  (Please  note,  here  the 
"  -  "  is  a  minus  sign,  not  the  abbreviation  for  the  word  "  to  ".)  Thus,  each  of  the  terms  inside 
the  brackets  in  the  numerator  has  units  of  (particles  /  cm^  -  sec  -  ster)  after  the  multiplications. 

Before  discussing  the  last  term  in  the  numerator  (a  constant),  the  denommator  will  be 
discussed.  The  term  in  the  denominator,  AE,,  is  the  narrowed  energy  channel  bandwidth,  m 
units  of  (keV).  For  example,  [  44  (keV)  -  30  (keV)  ]  =  14  (keV)  ,  and  [  64  (keV)  -  44  (keV)  ] 
=  20  (keV),  etc.  (Again,  the symbols  are  minus  signs.) 

Tracking  the  energy  units  of  numerator  and  denominator,  it  is  seen  that  the  Corrected 
Differential  Flux,  df  7  dE,  has  units  of  (particles  /  cm^-  sec  -  ster  -  keV).  These  are  the  same 

units  as  the  model  output  after  post-processing  of  those  data  files. 

The  differential  fluxes  found  by  the  method  above  are  essentially  average  flux  across 
the  narrowed  energy  channel  bandwidth.  In  the  Rice  methodology  reported  in  the  ETAC 
draft  report,  it  is  assumed  that  this  average  differential  flux  is  suitably  applied  at  the  center  of 
the  bandwidth  (2:8).  For  example,  the  average  flux  value  for  the  30-44  keV  channel  is 
assigned  to  the  37  keV  particles.  In  this  way,  satellite  data  is  finally  changed  to  a  form  which 
is  comparable  to  MSM  calculated  fluxes. 

The  last  term  in  the  numerator  of  Equation  2  is  a  channel  sensitivity  correction  factor. 
H.  Garrett  at  Rice  determined  that  certain  of  the  electron  sensors  underestimate  the  true  flux 
values  (8).  The  flux  values  for  these  channels  must  be  multiplied  by  a  correction  factor.  The 
constant  C  is  2.0  for  the  30-44  keV  channel  and  1 .4  for  the  44-64  keV  channel.  It  is  1 .0  (i.e. 
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no  correction)  for  all  other  channels,  including  all  proton  channels. 

4.6.2A  Final  Processing 

The  fourth  epconv./operation  is  self  explanatory.  The  log  10  of  each  dilFerential  flux 
value  is  calculated. 

The  fifth  e/;conv./ operation  simply  writes  the  results  to  a  file  in  the  correct  format  for 
optional  input  as  epsat  and  epions  files  into  the  MSM  model  for  use  in  the  opte/r  routine.  As 
previously  mentioned,  this  method  was  not  used  in  this  study. 

The  first  ep^c./operations  is  another  set  of  quality  control  measures.  It  is  enq)loyed  at 
this  point  to  remove  data  spikes.  Since  aU  flux  values  at  this  point  are  in  loglO  form,  each 
change  in  value  of  1 .0  represents  an  order  of  magmtude  change.  This  amount,  one  order  of 
magnitude,  was  selected  as  the  threshold  for  filtering  the  time  trace  of  flux  values  in  any 
single  narrow  energy  rhannel  This  means  that  if  the  observations  before  or  after  a  given  time 
tag  differ  from  that  reading  by  1 .0  or  more,  all  the  values  for  that  observation  are  discarded. 
The  assumption  here  is  that  average  flux  values  will  not  change  more  than  one  order  of 
magnitude  between  two  five  minute  intervals.  This  measure  discards  only  about  1  %  of  the 
data. 

The  second  ep^c./operation  is  surlily  a  change  of  format  to  make  the  final  display  of 
in  situ  satellite  flux  values  easy  to  visually  inspect.  The  compare/  software  written  for  this 
study,  which  does  the  squared  error  difference  calculations  between  model  and  satellite  fluxes, 
expects  the  satellite  values  to  be  in  this  format. 

Two  final  points  need  to  be  made  about  the  original  satellite  comparison  data  files. 
First,  each  set  of  values  is  tagged  with  a  longitude  number,  indicating  the  location  of  one  of 
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three  of  the  geosynchronous  satellites.  In  the  original  file,  two  of  the  locations  are  in  error. 
All  observations  tagged  at  205  degrees  actually  belong  to  the  70  degree  east  satellite,  and  vice 
versa.  This  was  confirmed  by  ETAC  through  personal  communication  with  R.  Belian  at  Los 
Alamos  (3).  Second,  many  more  channels  are  present  in  the  original  files  than  are  used  in  this 
study.  Since  the  MSM  only  produces  output  deemed  trustworthy  in  the  1-100  keV  range,  the 
higher  energy  channels  were  simply  ignored  (4:2-2). 

4.7  Post-Processing  Software  Issues 

AU  the  various  corollary  programs  used  external  to  MSM  have  been  discussed  in 
sufficient  detail  in  the  context  of  other  sections.  The  exception  to  this  is  the  compare./ 
software. 

This  program,  developed  at  AFIT,  is  used  to  accomplish  a  squared  error  accuracy 
analysis  between  the  in  situ  particle  flux  files  and  the  MSM  output  flux  files.  The  compare./ 
program  acconplish  one  more  interpolation  of  model  output  before  the  actual  comparison  of 
data  is  performed. 

Recall  that  the yb^/e./program  executed  a  spatial  interpolation  on  MSM  output  flux 
values.  The  cow/^am/program  must  now  perform  a  temporal  interpolation.  This  is 
necessary  because  in  situ  satellite  readings  come  at  approximately  five  minute  intervals  while 
model  outputs  come  at  fifteen  minute  intervals.  In  general,  the  time  tags  of  the  two  data  sets 
do  not  coincide.  In  order  to  maximize  the  number  of  data  points  compared,  the  time  tags  of 
the  in  situ  data  file  are  used  as  references,  and  then  a  linear  interpolation  is  executed  between 
MSM  outputs,  producing  model  flux  values  with  time  tags  which  match  those  of  the  in  situ 
flux  readings. 
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